|
From: <jue...@we...> - 2004-09-05 09:28:00
|
I agree that it might not be following the intent of every J2EE vendor =
out there. However, it is still not too far-fetched to consider the JTA =
TransactionManager as a kind of extension to the UserTransaction =
interface: If a vendor's UserTransaction object implements the =
TransactionManager interface too, it usually should be fully usable, =
else the vendor should just provide a facade that solely implements =
UserTransaction...
=20
Anyway, we can't easily turn off that autodetection by default, as some =
Spring users might rely on it. It also works nicely for a number of =
containers, for example Resin, Orion (OC4J), JOnAS (JOTM). And you can =
turn off autodetection now, via the "autodetectTransactionManager" flag, =
although the only case I know of where that is appropriate is the =
default JtaTransactionManager on WebLogic.
=20
Regarding full autodetection of the J2EE server: While that certainly is =
achievable, it's not as straightforward as it may seem at first glance. =
Migration between J2EE servers shouldn't be too hard anyway, as it just =
affects the JtaTransactionManager definition: The rest of the =
application can stay exactly the same. We currently leave it to the user =
to configure the JtaTransactionManager appropriately, and just include =
support classes for all sorts of cases.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Eugene Kuleshov
Gesendet: So 05.09.2004 05:06
An: spr...@li...
Betreff: Re: [Springframework-developer] WLS 7 and TX suspend/resume - =
continue.
j=FCrgen h=F6ller [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=3D"wls7tm"
>
> =
class=3D"org.springframework.transaction.jta.WebLogicServerTransactionMan=
agerFactoryBean"/>
> <bean id=3D"transactionManager"
>
> =
class=3D"org.springframework.transaction.jta.WebLogicJtaTransactionManage=
r">
> <property name=3D"transactionManager"> <ref local=3D"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=FCrgen h=F6ller [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=FCrgen h=F6ller [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=FCrgen h=F6ller [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.
>>>>
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|