You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by bu...@apache.org on 2005/04/29 12:10:02 UTC
DO NOT REPLY [Bug 34676] New: -
tm-commits=true = database corruption?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34676>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34676
Summary: tm-commits=true = database corruption?
Product: Slide
Version: Nightly
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: Stores
AssignedTo: slide-dev@jakarta.apache.org
ReportedBy: gblock@ctoforaday.com
I've been trying to get Slide to behave a bit better when it comes to how it handles its connections and
transactions; despite telling the access token that I wish to begin() and then commit() a transaction, I
noted that with tm-commits=true (and no tm set), not all operations were getting rolled back; the
database was left in a corrupted state.
The behvaior I'm expecting:
- If I call accessToken.begin(), all Slide operations within that begin/end pair will use the same
connection. getCurrentConnection() fails in most cases, and I end up using getNewConnection(), which
will lead to DB issues with locks.
- Setting tm-commits to true didn't do what I'd expected - instead, it appears that some things
committed, some things failed, and it left the database bereft and corrupt.
So, my questions are as follows:
- Is tm-commits flat-out unsupported unless you provide a transaction manager for it to use?
- Is the connection behavior normal?
- Would that connection behavior change if I *did* provide a transactionmanager implementation?
In effect, is this expected behavior? If so, should tm-commits flag be checking for a
TransactionManager implementation before allowing itself to be set to a mode where it can corrupt
data?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org