purequery questions are for IBMs ;) Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau
2014-10-17 8:19 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: > @Romain > > Is there something similar to checkDs that I can do when using EJBs, > Container Managed tx and PureQuery (which in turn gets connections from an > injected datasource and fires queries...). That is checkDs without JPA? > > Regards > LF > > On Thu, Oct 16, 2014 at 3:48 PM, Lars-Fredrik Smedberg <[email protected]> > wrote: > >> True haha... will have a look at it... I really want to learn the details >> (and in my case have to due to some design we are in the middle of)... >> >> Anyway... thanks for all help, preciate it! >> >> /LF >> >> On Thu, Oct 16, 2014 at 3:42 PM, Romain Manni-Bucau < >> [email protected]> wrote: >> >>> hehe you are curious, read >>> org.apache.openjpa.kernel.BrokerImpl#beforeCompletion. It basically >>> check all state of the entities >>> Romain Manni-Bucau >>> Twitter: @rmannibucau >>> Blog: http://rmannibucau.wordpress.com/ >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>> Github: https://github.com/rmannibucau >>> >>> >>> >>> 2014-10-16 15:38 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: >>> > Thanks for the answer >>> > >>> > What exactly is involved in a checkDs1() call? >>> > >>> > Regards >>> > LF >>> > >>> > On Thu, Oct 16, 2014 at 3:33 PM, Romain Manni-Bucau < >>> > [email protected]> wrote: >>> > >>> >> 2014-10-16 15:01 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: >>> >> > Thanks again, see below. >>> >> > >>> >> > On Thu, Oct 16, 2014 at 2:05 PM, Romain Manni-Bucau < >>> >> > [email protected]> wrote: >>> >> > >>> >> >> 2014-10-16 13:20 GMT+02:00 Lars-Fredrik Smedberg < >>> [email protected]>: >>> >> >> > Just one more thing I forgot to put in the other mail >>> >> >> > >>> >> >> > With "Depend, using ManagedConnection it will be green but it >>> will not >>> >> >> do what >>> >> >> > you expect." you mean that I will think it runs in a tx but its >>> not >>> >> and >>> >> >> in >>> >> >> > case of failure I might get inconsistency? >>> >> >> > >>> >> >> >>> >> >> right, if datasource2.commit() fails but ds1.commit() passed then >>> you >>> >> >> are not consistent. Of course with jpa it is not that impacting >>> since >>> >> >> >>> >> > >>> >> > Could you please explain how jpa tries to solve this? I guess it >>> will not >>> >> > completely remove the consisitency risk but only lower the risk? >>> >> > >>> >> >>> >> It doesn't but it limits it in practise. It basically do a check >>> >> before calling commit. All checks pass before commit: >>> >> >>> >> checkDs1(); >>> >> checkDs2(); >>> >> commitDs1(); >>> >> commitDs2(); >>> >> >>> >> so it avoids half of the ds2 commit fails but not ds1. >>> >> >>> >> > >>> >> >> the provider checks it before committing. >>> >> >> >>> >> >> >>> >> > So I guess in our case: non xa datasources with multiple connections >>> >> within >>> >> > a transaction we are not guaranteed consistency? >>> >> > >>> >> >>> >> Yep >>> >> >>> >> > I see also that some db vendors (MQ SQL) has some optimization so >>> >> > transactions involving multiple connections from different >>> datasources >>> >> but >>> >> > from the same db is not promoted to a distributed tx >>> >> > >>> >> > => Is that only vendor specific or is that according to spec to not >>> >> promote >>> >> > it in certain situations? >>> >> > >>> >> >>> >> vendor >>> >> >>> >> > >>> >> > resource = datasource != underlying db (without using openejb >>> >> >> aliases). Each datasource has its own pool of connection and then >>> its >>> >> >> own JTA integration (different Xid). >>> >> >> >>> >> >> > Regards >>> >> >> > LF >>> >> >> > >>> >> >> > On Thu, Oct 16, 2014 at 12:59 PM, Romain Manni-Bucau < >>> >> >> > [email protected]> wrote: >>> >> >> > >>> >> >> >> Well I don't know websphere enough to answer to the related >>> question >>> >> >> >> >>> >> >> >> >>> >> >> >> 2014-10-16 12:55 GMT+02:00 Lars-Fredrik Smedberg < >>> [email protected] >>> >> >: >>> >> >> >> > Thanks Romain, please see if you can help me on the follow up >>> >> below? >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > On Thu, Oct 16, 2014 at 9:33 AM, Romain Manni-Bucau < >>> >> >> >> [email protected]> >>> >> >> >> > wrote: >>> >> >> >> > >>> >> >> >> >> 2014-10-16 9:31 GMT+02:00 Lars-Fredrik Smedberg < >>> >> [email protected] >>> >> >> >: >>> >> >> >> >> > @Romain >>> >> >> >> >> > >>> >> >> >> >> > I can see in the ManagedConnection code that the reused >>> >> Connection >>> >> >> is >>> >> >> >> per >>> >> >> >> >> > Transaction per DataSource. >>> >> >> >> >> > >>> >> >> >> >> > So if I use 2 x DataSource (pointing to the same DB but with >>> >> >> different >>> >> >> >> >> > properties set) I will within a transaction use 2 >>> connections, >>> >> >> >> correct? >>> >> >> >> >> > >>> >> >> >> >> yep >>> >> >> >> >> >>> >> >> >> >> > Will this result in a distributed transaction? >>> >> >> >> >> > >>> >> >> >> >> >>> >> >> >> >> No, this ManagedConnection is to get JTA integration "locally" >>> >> (ie we >>> >> >> >> >> integrate locally with XA hooks but it is not distributed). >>> For >>> >> that >>> >> >> >> >> you have to use a really XA datasource. >>> >> >> >> >> >>> >> >> >> > >>> >> >> >> > We use WebSphere in test/production and the driver included in >>> >> >> >> db2jcc4.jar. >>> >> >> >> > >>> >> >> >> > As far as I understand from the documentation if the type >>> >> attribute of >>> >> >> >> the >>> >> >> >> > datasource element in the configuration is not set it will >>> search >>> >> the >>> >> >> >> > driver jar for datasources in the following order: >>> >> >> >> > >>> >> >> >> > javax.sql.ConnectionPoolDataSource >>> >> >> >> > javax.sql.DataSource >>> >> >> >> > javax.sql.XADataSource >>> >> >> >> > >>> >> >> >> > In our testconfiguration we do not specify the type attribute >>> so I >>> >> >> assume >>> >> >> >> > we are NOT using XA datasource. correct? >>> >> >> >> > >>> >> >> >> > So some questions on the above: >>> >> >> >> > >>> >> >> >> > 1. In what cases will I not need a distributed tx? >>> >> >> >> >>> >> >> >> You don't need it either when you have a single or totally >>> >> decorelated >>> >> >> >> resources (datasource for instane) or when you want performances >>> (XA >>> >> >> >> is slow) and can accept some manual operations to fix >>> inconsistency >>> >> if >>> >> >> >> it happens (should be rare) >>> >> >> >> >>> >> >> >> > a) A tx with 1 connection to a DB? No! >>> >> >> >> > b) A tx with 2 connections (from seperate datasources) >>> connected to >>> >> >> the >>> >> >> >> > same DB? <== ?? >>> >> >> >> > c) A tx with 2 connections (from seperate datasources) >>> connected to >>> >> >> >> > different DBs? Yes! >>> >> >> >> > d) A tx with 1 connection to a DB and e.g. JMS? Yes! >>> >> >> >> > >>> >> >> >> > 2. If I have a scenario that requires a distributed and the >>> >> datasource >>> >> >> >> that >>> >> >> >> > is used is NOT an XA datasource what will happen? Exception? >>> >> >> >> > >>> >> >> >> >>> >> >> >> Depend, using ManagedConnection it will be green but it will not >>> do >>> >> >> >> what you expect. >>> >> >> >> >>> >> >> >> > Thanks >>> >> >> >> > >>> >> >> >> > Regards >>> >> >> >> > Lars-Fredrik >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> >> >>> >> >> >> >> > Regards >>> >> >> >> >> > LF >>> >> >> >> >> > >>> >> >> >> >> > On Wed, Oct 15, 2014 at 8:48 AM, Romain Manni-Bucau < >>> >> >> >> >> [email protected]> >>> >> >> >> >> > wrote: >>> >> >> >> >> > >>> >> >> >> >> >> 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. >>> >> >> >> >> >> >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > -- >>> >> >> >> >> > 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. >>> >> >> >> >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > -- >>> >> >> > 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. >>> >> >>> > >>> > >>> > >>> > -- >>> > 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. >> > > > > -- > 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.
