[prev in list] [next in list] [prev in thread] [next in thread] 

List:       slide-dev
Subject:    DO NOT REPLY [Bug 34676]  New:  -
From:       bugzilla () apache ! org
Date:       2005-04-29 10:10:02
Message-ID: 20050429101002.14F4229C () ajax ! apache ! org
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]