DO NOT REPLY [Bug 7640] - JDBC connection and transaction related
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7640. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7640 JDBC connection and transaction related [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-04-22 13:46 --- This is a Tyrex problem, not a Tomcat problem, so it won't be fixed (at least not by Tomcat). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7640] - JDBC connection and transaction related
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7640. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7640 JDBC connection and transaction related [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Critical Status|RESOLVED|REOPENED Priority|Other |Medium Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2002-04-21 17:38 --- I don't agree with your comments. In distributed environment, this is not the case. If you take transaction manager of any application server like websphere, weblogic etc.. they behave the following way. 1-start the transaction, getconnection from datasource1 in object1. object1 wrote some data to the datasource1. 2-getconnection from the same datasource1 in object2(physically object2 can be running in another machine, so it is not feasible to pass the same connection object) returns another connection, but internal connection object that is database specific jdbc connection object will be same. 3-now object2 can read the data written by object1(this ditry read is only possible if the internal database connection object is same). 3. object2 closes the logical connection. object2 returns 4. object1 closes the logical connection 5. object1 commits the transaction. This behaviour works in the above said transaction managers/app servers. It works even if we close the object1 connection in the step 1 it self(instead of step 4). But it doesn't work in tyrex/tomcat. thank you -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7640] - JDBC connection and transaction related
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7640. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7640 JDBC connection and transaction related [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-04-21 02:23 --- I don't agree with your suggested behavior. IMHO, closing the allocated connection (which really just returns it to the pool) should roll back any current transaction that is in progress. If you want to maintain the transaction, you should hold on to the connection it was started with and continue to use it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
