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: [email protected]
        ReportedBy: [EMAIL PROTECTED]


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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to