Well we could with some caveats. 1) If using a TSR-backed JtaPlatform no features leveraging suspend/resume would be available; this includes (limited to?) org.hibernate.engine.transaction.internal.jta.JtaIsolationDelegate 2) Infinispan has its notion of a "TransactionManagerLookup", and hibernate-infinispan has an impl that bridges through to our JtaPlatform to retrieve the TM. No clue the ramification here. Though I can't imagine that Infinispan needs suspend/resume.
On Fri 16 Mar 2012 09:54:23 AM CDT, Scott Marlow wrote: > Yes, but I wonder if we could squash down what we require to what > http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html > > offers. > > We aren't the only persistence provider still using the Transaction > Manager directly either. I still like my original proposal to > introduce a standard way of accessing the TM but if we truly could > avoid using the TM (when running with a EE server), that might be > worth attempting. > > On 03/16/2012 10:45 AM, Steve Ebersole wrote: >> Unfortunately JtaPlatform covers more than just sync registration... >> >> >> On Fri 16 Mar 2012 09:43:45 AM CDT, Scott Marlow wrote: >>> I was just thinking about this related eg discussion >>> http://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-10/message/3 >>> >>> >>> from last fall and wonder if the default could be something like: >>> >>> if attempt to use jndi naming and lookup >>> TransactionSynchronizationRegistry works, use the TSR. >>> >>> else, look for hints in the environment (standalone case since all EE >>> implementations should be using TSR). This could also cover use on EE >>> servers that are either non-compliant or for other reason cannot >>> return the TSR. >>> >>> >>> On 03/16/2012 09:28 AM, Steve Ebersole wrote: >>>> Good point. I added that flag to the JIRAs >>>> >>>> On Fri 16 Mar 2012 08:06:53 AM CDT, Emmanuel Bernard wrote: >>>>> Yes that covers it all. >>>>> By the way these are perfect issues for somebody wanting to step up >>>>> but not knowning the Hibernate code base. This is quite isolated. >>>>> >>>>> On 16 mars 2012, at 13:56, Steve Ebersole wrote: >>>>> >>>>>> In case anyone is interested: >>>>>> >>>>>> https://hibernate.onjira.com/browse/HHH-6823 >>>>>> https://hibernate.onjira.com/browse/HHH-5951 >>>>>> >>>>>> >>>>>> On Thu 15 Mar 2012 03:21:56 PM CDT, Steve Ebersole wrote: >>>>>>> I like #2 as well. There is already a JIRA for that. In addition >>>>>>> there is also a JIRA for adding some auto-detection in 5.0 >>>>>>> >>>>>>> On Thu 15 Mar 2012 11:40:07 AM CDT, Emmanuel Bernard wrote: >>>>>>>> Because you need to know the JtaPaltform class name to fill up >>>>>>>> hibernate.transaction.jta.platform, I find it curious that these >>>>>>>> classes are in internal. >>>>>>>> I might decide to delete one of them and not care as they are in >>>>>>>> internal but that will impact the user. >>>>>>>> >>>>>>>> I see two options: >>>>>>>> >>>>>>>> 1. create subclasses in a non internal package >>>>>>>> 2. create shortcuts for the built-in platforms (weblogic, >>>>>>>> websphere-5, websphere-6, etc) >>>>>>>> >>>>>>>> >>>>>>>> I like option 2 better as it makes configurations more readable. >>>>>>>> >>>>>>>> WDYT? >>>>>>>> _______________________________________________ >>>>>>>> hibernate-dev mailing list >>>>>>>> hibernate-dev@lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>> >>>>>> >>>>>> -- >>>>>> st...@hibernate.org >>>>>> http://hibernate.org >>>>> >>>> >>> >> > -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
