Hi that's the global idea yes
about transaction manager: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.geronimo.components/geronimo-transaction/3.1.1/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java#TransactionManagerImpl is th eone idea is simple: invoke registered hooks when needed and just manage the lifecycle then EJB containers start/stop these hooks calling the tx mgr (look SingletonContainer hierarchy in openejb-core for instance) Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-10-15 1:19 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: > Hi Romain > > Thanks for the link to the ManagedConnection, some questions on it (so I > understand it correctly) > > - The connection is bound to the tx when the first method is called on the > connect (except for toString, equals and hashcode), and if its not already > bound, correct? > - Do I understand correctly that I will always use (using delegation in the > proxy) the same connection (the one bound to the tx) regardless of if I use > getConnection()/close() multiple times within an EJB that handles tx? > - In the above case the connection I think I'm using (when I simple look at > the code) is returned to the pool and the bound one is used? > > Where can I get more understanding of the TransactionManager and its > relation to the transactions annotated in the EJB? > > Very nice to take a look at the code, really makes the understanding alot > easier, thanks! > > /LF > > > On Wed, Oct 15, 2014 at 1:03 AM, Romain Manni-Bucau <[email protected]> > wrote: > >> Hi >> >> this is actually more bound to JTA (you can read >> >> http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/resource/jdbc/managed/local/ManagedConnection.java >> ) >> >> >> 2014-10-15 0:14 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: >> > Hi >> > >> > Using JDBC, creating a connection and setting it to auto commit false to >> be >> > able to group more than one statement into a single transaction I >> > understand. >> > >> > - Is it possible to compare that to an EJB with a @TransactionAttribute >> > set? I would like to understand more in detail how the EJB handles >> > transactions, datasources and connections "under the hood". >> > (it all comes from a discussion with a DBA) >> > >> > If I use @Resource to inject a Datasource and use to retrieve a >> connection >> > I usually call close on it after I done using it, >> > >> > - Will close on the connection actually close it or is that done at the >> > commit of the transaction (assume we are in an EJB with >> > @TransactionAttribute set)? >> >> will be done later to support rollback >> >> > - Will the container automatically set auto commit false to any >> connections >> > retrieved within the transaction? >> >> all JTA ones, can also depend on JPA provider config >> >> > - ... and many more questions :) >> > >> > Maybe I'm mixing the topics a bit but it would be really great to >> > understand it all more in-depth to be able to have the understanding and >> > discuss it with the DBA. >> > >> > Thanks >> > >> > >> > >> > -- >> > Med vänlig hälsning / Best regards >> > >> > Lars-Fredrik Smedberg >> > >> > STATEMENT OF CONFIDENTIALITY: >> > The information contained in this electronic message and any >> > attachments to this message are intended for the exclusive use of the >> > address(es) and may contain confidential or privileged information. If >> > you are not the intended recipient, please notify Lars-Fredrik Smedberg >> > immediately at [email protected], and destroy all copies of this >> > message and any attachments. >> > > > > -- > Med vänlig hälsning / Best regards > > Lars-Fredrik Smedberg > > STATEMENT OF CONFIDENTIALITY: > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of the > address(es) and may contain confidential or privileged information. If > you are not the intended recipient, please notify Lars-Fredrik Smedberg > immediately at [email protected], and destroy all copies of this > message and any attachments.
