[infinispan-dev] UserTransactionLookup for JSR-107?

[Dan Berindei]

Galder, the CacheManager.getUserTransaction() javadoc says the method
should return "a" UserTransaction. It doesn't mandate any connection with
any active TM, in fact based on this issue I think Ehcache will always
return their own UserTransaction object:
https://github.com/jsr107/jsr107spec/issues/28

The Javadoc of the methods in UserTransaction and in TransactionManager in
the standard are identical. So if they don't behave the same, that's a bug
in the TM.

Case in point, I just looked at JBossTS version 4.16.3 and
UserTransactionImple doesn't do anything except extend BaseTransaction.
TransactionManagerImple also extends BaseTransaction and adds a few extra
methods. BaseTransaction doesn't have any instance state (it's all statics
and thread locals), so UserTransactionImple and TransactionManagerImple are
identical except for the extra methods in TransactionManagerImple.

Cheers
Dan



On Fri, Feb 8, 2013 at 11:18 AM, Galder Zamarreño <galder at redhat.com> wrote:

> I'm no transactions expert, but I did consider that and I highly doubt
> it's that simple.
>
> Even if it might probably just work, you'll never be able to guarantee
> that such UserTransaction behaves just like You-Fav-JTATM-UserTransaction
> without throrough testing.
>
> Go to your IDE (dunno where JBoss TS source code is online…) and open up:
> - com.arjuna.ats.internal.jta.transaction.arjunacore.UserTransactionImple
> - com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction
>
> Cheers,
>
> On Feb 7, 2013, at 2:17 PM, Dan Berindei <dan.berindei at gmail.com> wrote:
>
> > Do we really need to expose the TransactionManager's UserTransaction
> implementation?
> >
> > Looking at the interface, it seems like a subset of TransactionManager,
> so couldn't we return a custom UserTransaction that just delegates to the
> TransactionManager?
> >
> >
> > On Thu, Feb 7, 2013 at 2:06 PM, Manik Surtani <msurtani at redhat.com>
> wrote:
> > Ok.  Then a separate Lookup is what we'd need, I guess.  Not pretty, but
> oh well.
> >
> > On 7 Feb 2013, at 11:41, Galder Zamarreño <galder at redhat.com> wrote:
> >
> > >
> > > On Feb 7, 2013, at 12:31 PM, Manik Surtani <msurtani at redhat.com>
> wrote:
> > >
> > >>
> > >> On 7 Feb 2013, at 11:23, Galder Zamarreño <galder at redhat.com> wrote:
> > >>
> > >>> Hi all,
> > >>>
> > >>> I'm back with a more food for thought wrt JSR-107 impl. Our
> CacheManager adapter needs to implement:
> > >>>
> > >>> UserTransaction getUserTransaction();
> > >>>
> > >>> The problem there is that there's no standard way of getting a
> UserTransaction given a JTA TransactionManager.
> > >>>
> > >>> It really is down to each TransactionManager provider to give a
> UserTransaction instance (whether JNDI, static…etc).
> > >>>
> > >>> So, we need a way to lookup a UserTransaction.
> > >>>
> > >>> One option is to add a getUserTransaction to
> TransactionManagerLookup, but that will break existing clients.
> > >>
> > >> You mean it would break existing TML implementations?
> > >
> > > ^ Yeah, potentially yeah.
> > >
> > >> Do we know of any custom TML implementations though?
> > >
> > > Yes:
> > > -
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/tm/HibernateTransactionManagerLookup.java
> > > -
> https://github.com/jbossas/jboss-as/blob/master/clustering/infinispan/src/main/java/org/jboss/as/clustering/infinispan/TransactionManagerProvider.java
> > >
> > >>
> > >>>
> > >>> Alternatively, define a
> org.infinispan.transaction.lookup.UserTransactionLookup interface which is
> configurable. We'd then need to implement for existing TML classes.
> > >>>
> > >>> If anyone has any other ideas, let us know.
> > >>>
> > >>> Cheers,
> > >>> --
> > >>> Galder Zamarreño
> > >>> galder at redhat.com
> > >>> twitter.com/galderz
> > >>>
> > >>> Project Lead, Escalante
> > >>> http://escalante.io
> > >>>
> > >>> Engineer, Infinispan
> > >>> http://infinispan.org
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> infinispan-dev mailing list
> > >>> infinispan-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > >>
> > >> --
> > >> Manik Surtani
> > >> manik at jboss.org
> > >> twitter.com/maniksurtani
> > >>
> > >> Platform Architect, JBoss Data Grid
> > >> http://red.ht/data-grid
> > >>
> > >>
> > >> _______________________________________________
> > >> infinispan-dev mailing list
> > >> infinispan-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > >
> > >
> > > --
> > > Galder Zamarreño
> > > galder at redhat.com
> > > twitter.com/galderz
> > >
> > > Project Lead, Escalante
> > > http://escalante.io
> > >
> > > Engineer, Infinispan
> > > http://infinispan.org
> > >
> > >
> > > _______________________________________________
> > > infinispan-dev mailing list
> > > infinispan-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> > --
> > Manik Surtani
> > manik at jboss.org
> > twitter.com/maniksurtani
> >
> > Platform Architect, JBoss Data Grid
> > http://red.ht/data-grid
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130208/cb996691/attachment.html