tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@tomitribe.com>
Subject Re: JDBC Transactions vs EJBs and @TransactionAttribute(...) and more...
Date Thu, 16 Oct 2014 10:59:02 GMT
Well I don't know websphere enough to answer to the related question


2014-10-16 12:55 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
> 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 <rmannibucau@gmail.com>
> wrote:
>
>> 2014-10-16 9:31 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
>> > @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 <
>> rmannibucau@gmail.com>
>> > 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 <itsmeden@gmail.com>:
>> >> > 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 <
>> >> rmannibucau@gmail.com>
>> >> > 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 <itsmeden@gmail.com
>> >:
>> >> >> > 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 itsmeden@gmail.com, 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 itsmeden@gmail.com, 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 itsmeden@gmail.com, 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 itsmeden@gmail.com, and destroy all copies of this
> message and any attachments.

Mime
View raw message