RE: [Springframework-developer] WLS 7 and TX suspend/resume - continue.

[<jue...@we...>]

Eugene,
=20
We have such autodetection in a variety of places, for example =
HibernateTransactionManager and JdoPersistenceManager which autodetect =
an underlying DataSource, to be able to expose Hibernate respectively =
JDO transactions as JDBC transactions. As of 1.1 final, those =
autodetection mechanisms can be turned off too, but we've explicitly =
been asked to autodetect by default.
=20
While I do see that autodetection of the JTA TransactionManager might =
not be desirable on WebLogic 7.0, I don't think that this a big deal: =
Simply turn it off via the "autodetectTransactionManager" flag. On a =
variety servers, autodetection eases configuration, as there is no need =
for server-specific configuration in that case. Frankly, if that =
autodetection on WebLogic 7 is the biggest issue that we have to worry =
about, I'm more than happy.
=20
Regarding auto-adapting to the J2EE server version and choosing an =
appropriate lookup strategy: We don't do that in other places either, =
currently: for example, NativeJdbcExtractors for a specific connection =
pool. We do have a simple strategy that works on many connection pool =
there: SimpleNativeJdbcExtractor, fetching the native connection via =
con.getMetaData().getConnection() - but that one still has to be =
explicitly specified.
=20
So in some respect, Spring is currently not designed to autodetect =
everything for you, but rather to make it easy for you to plug in =
appropriate strategies. You can easily factor the JtaTransactionManager =
definition out into its own XML bean definition file, or define a =
variety of combinations that are all marked as lazy-init, plugging a =
specific one in via a ${...} placeholder for the target reference of =
transaction proxies. There's a variety of options, actually.
=20
Auto-adapting to the J2EE server is not that trivial because it incurs a =
check for specific server versions: On WebLogic 8.1, use a default =
WebLogicJtaTransactionManager; on WebLogic 7.0, use a =
WebLogicJtaTransactionManager with =
WebLogicServerTransactionManagerFactoryBean. It's certainly *possible*, =
but it has to be discussed whether it's *desirable* as part of Spring.
=20
As a side note, Hibernate doesn't autodetect the J2EE server either, but =
rather requires you to explicitly specify an appropriate =
TransactionManagerLookup as Hibernate property. Kodo JDO on the other =
hand autodetects, if I'm not mistaken. Don't get me wrong: We might =
introduce such auto-adaption at a later point of time. It's just not =
that crucial, IMHO; in particular, it's no reason to defer 1.1 final.
=20
Juergen
=20

________________________________

From: spr...@li... on behalf of =
Eugene Kuleshov
Sent: Sun 05/09/2004 16:24
To: spr...@li...
Subject: Re: [Springframework-developer] WLS 7 and TX suspend/resume - =
continue.



j=FCrgen h=F6ller [werk3AT] wrote:

> 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...

   That is not my point. The point is if user is passing property A, why =
it
should affect property B anyway? If he need to do something about B, why =
not
to use that B at the first place (e.g. since it is all reflection, you =
can
pass UserTransaction instance to TansactionManager setter, which will be =
more
straightforward).

> 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.

   It doesn't matter where it works. It looks like ugly hack anyway. :-)

> Regarding full autodetection of the J2EE server: While that certainly =
is
> achievable, it's not as straightforward as it may seem at first =
glance.

   Why is that?

> 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.

   I didn't say it is hard, it just lead to multiple spring contexts - =
one per
each application server and so far it is the only place where you have =
to do this.

   regards,
   Eugene


________________________________
>
> 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