tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lars-Fredrik Smedberg <itsme...@gmail.com>
Subject Re: JDBC Transactions vs EJBs and @TransactionAttribute(...) and more...
Date Thu, 16 Oct 2014 13:48:23 GMT
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 <
rmannibucau@tomitribe.com> 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 <itsmeden@gmail.com>:
> > 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 <
> > rmannibucau@tomitribe.com> wrote:
> >
> >> 2014-10-16 15:01 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
> >> > Thanks again, see below.
> >> >
> >> > On Thu, Oct 16, 2014 at 2:05 PM, Romain Manni-Bucau <
> >> > rmannibucau@tomitribe.com> wrote:
> >> >
> >> >> 2014-10-16 13:20 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com
> >:
> >> >> > 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 <
> >> >> > rmannibucau@tomitribe.com> 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 <
> 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.
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message