|
From: Eugene K. <eu...@md...> - 2004-09-05 03:07:35
|
jürgen höller [werk3AT] wrote:
> Thanks, Thomas - it's great to have this for 1.1 final!
>
> Did you have a chance to check whether WebLogic 8.1's UserTransaction
> object found at "java:comp/UserTransaction" implements the
> javax.transaction.TransactionManager interface too? It does so on WebLogic
> 7.0. The benefit of such a scenario is that Spring's JtaTransactionManager
> will autodetect the TransactionManager, without any special setup.
This autodetect feature looks like a half baked solution (or dirty hack).
You souldn't really rely on the fact that vendor choose to implement both
interfaces in publically available instance.
If you want to have smart tx proxy, it should autodetect j2ee container
vendor and version and then choose right way to retrieve tx proxy. Of course
it has to be tested carefuly for each environment, but then users can really
trust Spring's tx management and can use it without struggling with
configuration for each environment type. That will also simplify moving
application from one container to another (e.g. from Weblogic to Websphere).
> I've documented the basic JTA setup options for popular J2EE servers in
> JtaTransactionManager's javadoc. It would be good to verify whether my
> autodetection comment just applies to WebLogic 7.0 or also to WebLogic 8.1.
regards,
Eugene
> ________________________________
>
> Von: spr...@li... im Auftrag von
> Thomas Risberg Gesendet: Sa 04.09.2004 17:42 An:
> spr...@li... Betreff: Re:
> [Springframework-developer] WLS 7 and TX suspend/resume - continue.
>
>
>
> Juergen, Eugene, Dimitry, all WLS 70 users,
>
> We now have a new WebLogicServerTransactionManagerFactoryBean. This bean
> factory looks up the ServerTransactionManagerImpl to get around the NPE
> that was thrown during a "forceResume". I based the code on the WebSphere
> variant. This has been tested on WebLogic 7.0 SP5 and checked in. Here is
> a snippet from the configuration I tested with:
>
> <!-- transaction manager --> <bean id="wls7tm"
>
> class="org.springframework.transaction.jta.WebLogicServerTransactionManagerFactoryBean"/>
> <bean id="transactionManager"
>
> class="org.springframework.transaction.jta.WebLogicJtaTransactionManager">
> <property name="transactionManager"> <ref local="wls7tm"/> </property>
> </bean>
>
> Thomas
>
>
> Thomas Risberg wrote:
>
>
>> Juergen,
>>
>> I'll try to implement and test a
>> WebLogicServerTransactionManagerFactoryBean today. I'll keep you posted.
>>
>>
>> For WLS 8.1 the TxHelper.getTransactionManager method is marked as
>> deprecated even though it is not documented as such in the JavaDocs.
>> There is also a brand new method getClientTransactionManager for 8.1 that
>> is starting out marked as deprecated. Go figure. We are probably better
>> off recommending the JNDI lookups for 8.1.
>>
>> Thomas
>>
>>
>>
>> jürgen höller [werk3AT] wrote:
>>
>>
>>> Thanks, Thomas! This means that there *is* a way to make it work on
>>> WebLogic 7! Eugene, Dmitri, your pain finally has an end! :-)
>>>
>>> Regarding obtaining the TransactionManager via the TxHelper on WebLogic
>>> 7: That can easily be factored out into a custom FactoryBean, like we
>>> did for WebSphere (see WebSphereTransactionManagerFactoryBean), to be
>>> passed into JtaTransactionManager's respectively
>>> WebLogicJtaTransactionManager's "transactionManager" property. So we
>>> don't need a further JtaTransactionManager subclass for this, just a
>>> further TransactionManager lookup strategy.
>>>
>>> BTW, Dmitri told me that the WebLogic UserTransaction object at
>>> "java:comp/UserTransaction" implements the TransactionManager interface
>>> too, but that obviously forceResume doesn't work there... I assume the
>>> ClientTransactionManagerImpl is returned there, not the
>>> ServerTransactionManagerImpl.
>>>
>>> If we can double-check that this works better than the
>>> TransactionManager fetched from JNDI, I suggest to add a
>>> WebLogicServerTransactionManagerFactoryBean (or a similar name),
>>> clearly documenting that this is meant as an alternative to the
>>> standard JNDI TransactionManager reference that WebLogic provides,
>>> mainly for WebLogic 7. I wouldn't mind to do this even for the 1.1
>>> final release tomorrow...
>>>
>>> Is the TxHelper lookup available on WebLogic 8.1 too? Of course, it
>>> shouldn't be necessary there, as the standard JNDI TransactionManager
>>> reference will work too. I just wonder whether it's available and would
>>> work in principle: People could then configure a
>>> WebLogicServerTransactionManagerFactoryBean to be able to deploy on
>>> both WebLogic 7 and WebLogic 8, without adapting their Spring
>>> configuration.
>>>
>>> Of course, such a WebLogicServerTransactionManagerFactoryBean would
>>> have to be coded via reflection to avoid compile-time dependencies on
>>> WebLogic, analogous to WebSphereTransactionManagerFactoryBean. Do you
>>> have the chance to do this before tomorrow, Thomas?
>>>
>>> Juergen
>>>
>>>
>>> ________________________________
>>>
>>> Von: spr...@li... im Auftrag
>>> von Thomas Risberg Gesendet: Sa 04.09.2004 14:30 An:
>>> spr...@li... Betreff: Re:
>>> [Springframework-developer] WLS 7 and TX suspend/resume - continue.
>>>
>>>
>>>
>>> I have done some additional testing for this issue and this is what I
>>> have found.
>>>
>>> WebLogic exposes a client TransactionManager implementation via JNDI
>>> (weblogic.transaction.internal.ClientTransactionManagerImpl) and in WLS
>>> 7.0 it is throwing an NPE when you call forceResume (with or without a
>>> suspended transaction that has been marked for RollbackOnly).
>>>
>>> They also have a different server implementation
>>> (weblogic.transaction.internal.ServerTransactionManagerImpl) that is
>>> returnd by a call to TxHelper.getTransactionManager(). With this TM
>>> the force resume works as expected.
>>>
>>> So the workaround for now is to do the suspend/resume using the TM
>>> returned by TxHelper before calling the Spring managed code.
>>> Alternatively we could provide a WebLogic7JtaTransactionManager that
>>> uses this method of obtaining the TM.
>>>
>>> I doubt that BEA will fix this issue in WLS 7.0. They will probably
>>> suggest to upgrade to 8.1 or use the TxHelper to obtain the TM.
>>>
>>> Thomas
>>>
>>>
>>> jürgen höller [werk3AT] wrote:
>>>
>>>
>>>
>>>
>>>> Ideally, WebLogic should work properly with standard JTA
>>>> TransactionManager resume in all cases, not needing the proprietary
>>>> forceResume call. However, the least we can expect is that
>>>> forceResume works properly: You could send a corresponding bug report
>>>> to BEA, for WebLogic 7.0. However, they might tell you that they
>>>> fixed the issue in WebLogic 8.1...
>>>>
>>>> Juergen
>>>>
>>>>
>>>> ________________________________
>>>>
>>>> Von: spr...@li... im Auftrag
>>>> von jürgen höller [werk3AT] Gesendet: Fr 03.09.2004 23:31 An:
>>>> spr...@li... Betreff: Re:
>>>> [Springframework-developer] WLS 7 and TX suspend/resume - continue.
>>>>
>>>>
>>>>
>>>> As I already wrote in my JIRA comments: Many thanks for your efforts,
>>>> Dmitri!
>>>>
>>>> I assume that with JtaTransactionManager, you'll get an
>>>> IllegalStateException ("cannot resume rollback-only transaction" or
>>>> the like), and with WebLogicJtaTransactionManager, you'll get the NPE
>>>> in WebLogic code?
>>>>
>>>> This really seems to be a bug in WebLogic 7.0... At least it should
>>>> work properly as long as not suspending a transaction that has been
>>>> marked as rollback-only.
>>>>
>>>> Juergen
>>>>
>>>>
>>>> ________________________________
>>>>
>>>> Von: spr...@li... im Auftrag
>>>> von Dmitri Maximovich Gesendet: Fr 03.09.2004 23:07 An:
>>>> spr...@li... Betreff:
>>>> [Springframework-developer] WLS 7 and TX suspend/resume - continue.
>>>>
>>>>
>>>>
>>>> I just tried WLS 7 with Spring 1.1rc2 and BMT transaction
>>>> demaraction. It doesn't work with standard JtaTransactionManager or
>>>> with WeblogicJtaTransactionManager, so something fundamentally broken
>>>> in WLS7 (same NPE as described in JIRA SPR-251). Next I'll try to use
>>>> WLS TransactionManager (exposed in JNDI) to suspend/resume
>>>> transaction without Spring to see it it's going to work.
>>>>
|