On Feb 8, 2013, at 4:22 PM, Dan Berindei <dan.berindei(a)gmail.com> wrote:
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.
^ You're right, I hadn't noticed TransactionManagerImple extended BaseTransaction
too.
Cheers,
Cheers
Dan
On Fri, Feb 8, 2013 at 11:18 AM, Galder Zamarreño <galder(a)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(a)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(a)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(a)redhat.com> wrote:
>
> >
> > On Feb 7, 2013, at 12:31 PM, Manik Surtani <msurtani(a)redhat.com> wrote:
> >
> >>
> >> On 7 Feb 2013, at 11:23, Galder Zamarreño <galder(a)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-infinisp...
> > -
https://github.com/jbossas/jboss-as/blob/master/clustering/infinispan/src...
> >
> >>
> >>>
> >>> 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(a)redhat.com
> >>>
twitter.com/galderz
> >>>
> >>> Project Lead, Escalante
> >>>
http://escalante.io
> >>>
> >>> Engineer, Infinispan
> >>>
http://infinispan.org
> >>>
> >>>
> >>> _______________________________________________
> >>> infinispan-dev mailing list
> >>> infinispan-dev(a)lists.jboss.org
> >>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >>
> >> --
> >> Manik Surtani
> >> manik(a)jboss.org
> >>
twitter.com/maniksurtani
> >>
> >> Platform Architect, JBoss Data Grid
> >>
http://red.ht/data-grid
> >>
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev(a)lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> > --
> > Galder Zamarreño
> > galder(a)redhat.com
> >
twitter.com/galderz
> >
> > Project Lead, Escalante
> >
http://escalante.io
> >
> > Engineer, Infinispan
> >
http://infinispan.org
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik(a)jboss.org
>
twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
>
http://red.ht/data-grid
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev