springframework-developer — Spring Framework developers list

Re: [Springframework-developer] JTA transaction suspension on WebSphere

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

> Isn user transaction object available trough bean context wrapper?

Only for BMT, according to the EJB spec:

"The getUserTransaction method returns the =
javax.transaction.UserTransaction
interface. The instance can use this interface to demarcate transactions =
and to obtain transaction status. Only instances of a session bean with =
bean-managed transaction demarcation can use this method."

According to the spec, CMT beans are not supposed to touch direct JTA at =
all, not even the UserTransaction. While that still might work on some =
containers, you're outside the EJB spec here. And according to the BEA =
docs, WebLogic just officially supports the JTA TransactionManager for =
BMT too...


>> So I recommend to *either* work with EJB CMT *or* Spring-managed
>> transactions. Do not try to combine both unless you're aware that
>> you're violating the EJB spec.=20

> Hey, that was my point! :-)

OK, I admit I stole it, ehm, came to the same conclusion on my own ;-) =
However, it's important to explicitly state that using Spring-managed =
transactions with suspend/resume via the JTA TransactionManager *is* =
officially supported on WebLogic, for EJB BMT and web components.


>> However, EJB BMT with Spring-managed
>> transactions should work nicely, even if involving the JTA
>> TransactionManager on WebLogic.

> I wonder if anyone tested it?

I assume that it works with BMT on WebLogic 8.1, as it even works with =
CMT there. According to the BEA docs, it should work with BMT on =
WebLogic 7.0: This is explicitly stated there. They don't mention using =
JTA within EJB CMT, though, so I assume that combo is not officially =
supported.


> Anyway using BMT does not have much value, especially with MDB's and=20
> I believe it will also increase risks of losing data in case of=20
> container failures/crashes (XA transaction manger use heuristics in =
this=20
> case and should roll back everything correctly).

Effectively, MDBs should be the only problem, as we can't do =
transactional message reception without CMT there.

With BMT session beans or web components, Spring-managed transactions =
with JtaTransactionManager should be as powerful as CMT session beans, =
including transaction suspension and full recovery capabilities (which =
are provided by the JTA transaction manager, not by the EJB container).


> So, now it is unclear if it does work on WLS 8 in CMT scenario?

Thomas just clarified that he indeed tested this on CMT, so it does work =
with CMT on WebLogic 8. That combo still outside of the EJB spec, =
though.


Juergen


> -----Original Message----- From:
> spr...@li...=20
> [mailto:spr...@li...]On
> Behalf Of Eugene Kuleshov Sent: Thursday, September 02, 2004 1:23 PM=20
> To: spr...@li... Cc: Dmitri
> Maximovich Subject: Re: [Springframework-developer] JTA transaction
> suspension on WebSphere
>=20
>=20
> Juergen,
>=20
> If I'm reading this correctly, JTA transaction manager interface in
> Weblogic available to beans that are managing transactions
> themselves, but not suppose to be used by beans under CMT.
>=20
> regards, Eugene
>=20
>=20
>=20
>> A further update: I've just discovered that WebLogic even
>> officially supports javax.transaction.TransactionManager as public
>> API!
>>=20
>> http://e-docs.bea.com/wls/docs70/jta/jtaapi.html
>>=20
>> "Client-initiated transactions-the JTA transaction manager
>> interface (javax.transaction.TransactionManager) is made available
>> to clients and bean providers through JNDI. This allows clients and
>> EJBs using bean-managed transactions to suspend and resume
>> transactions."
>>=20
>> They only interpret the semantics of resume a bit differently, i.e.
>> not automatically resuming a transaction that has been marked
>> rollback-only. They explicitly offer their proprietary forceResume
>> method for this. It's quite clearly a bug then that it doesn't work
>> in WebLogic 7.0: We could even try to report that to BEA! It does
>> work in WebLogic 8.1, though...
>>=20
>> So in principle, suspend/resume via the JTA TransactionManager *is*
>>  supported by WebLogic, just with special semantics. And if you
>> need the forceResume semantics, you can use Spring's new=20
>> WebLogicJtaTransactionManager. Essentially, the JTA spec should be
>> clearer about the semantics of TransactionManager.resume here...
>>=20
>=20
>=20
>>=20
>> ________________________________
>>=20
>> Von: spr...@li... im
>> Auftrag von j=FCrgen h=F6ller [werk3AT] Gesendet: Mi 01.09.2004 22:01
>> An: spr...@li... Betreff: Re:=20
>> [Springframework-developer] JTA transaction suspension on WebSphere
>>=20
>>=20
>>=20
>>=20
>> An update: The issue was indeed caused by Spring's transaction=20
>> synchronization in combination with EJB CMT transaction suspension.
>> Once you turn off Spring's transaction synchronization, which
>> causes our Hibernate support to fall back to direct JTA
>> synchronization, everything works nicely. I've also refined our
>> Hibernate LOB types to be able to work with direct JTA
>> synchronization too, so that our full Hibernate support works in
>> such a scenario without hassle.
>>=20
>> Furthermore, Victor was so kind to test a variety of combinations
>> with Spring-driven JTA transaction suspension on WebSphere, among
>> those with an outer transaction that has been marked rollback-only
>> (which doesn't work out-of-the-box on WebLogic). Fortunately,
>> everything worked nicely!
>>=20
>> Thus, it's now quite safe to assume that WebSphere's JTA
>> TransactionManager is fully compatible with Spring, at least on
>> WebSphere 4. It would be good to get some tests on WebSphere 5 -
>> any volunteers? This means, to the best of our current knowledge,
>> that we only need special handling (WebLogicJtaTransactionManager)
>> on WebLogic, and that the only container where suspend/resume
>> doesn't work in all cases is WebLogic 7.
>>=20
>> Juergen
>>=20
>>=20
>> ________________________________
>>=20
>> Von: spr...@li... im
>> Auftrag von j=FCrgen h=F6ller [werk3AT] Gesendet: Di 31.08.2004 10:58
>> An: spr...@li... Betreff: Re:=20
>> [Springframework-developer] JTA transaction suspension on WebSphere
>>=20
>>=20
>>=20
>>=20
>> Indeed, Thomas: I've pointed out exactly the same to Eugene on that
>>  WebLogic issue in JIRA.
>>=20
>> FYI, I've just noticed that I might have misinterpreted Victor's
>> problem last night: He doesn't use Spring transactions with
>> REQUIRES_NEW, but rather an outer Spring transaction plus an inner
>> EJB CMT transaction with REQUIRES_NEW. Spring's
>> JtaTransactionManager never touches the JTA TransactionManager is
>> such a scenario, so it can't be caused by the suspend/resume
>> interaction there.
>>=20
>> I rather suspect that the problem is Spring's transaction
>> synchronization, which gets activated for the outer Spring
>> transaction, but doesn't get notified of the transaction suspension
>> caused by the inner EJB CMT transaction. Therefore, Spring's
>> Hibernate support within the inner transaction will still
>> synchronize with the outer Spring transaction, flushing the
>> Hibernate Session at completion of the *outer* rather than the=20
>> inner transaction.
>>=20
>> The solution I've suggested is to turn off Spring's transaction=20
>> synchronization in that case. It should always be turned off when
>> using transaction suspension driven by EJB CMT. See my JIRA
>> comments:
>>=20
>> http://opensource.atlassian.com/projects/spring/browse/SPR-295
>>=20
>> As I've noted there, it would still be interesting whether
>> Spring-driven JTA transaction suspension works with WebSphere:
>> i.e., a Spring transaction demarcation with REQUIRES_NEW in case of
>> an existing transaction. We might still face problems there, of
>> course, but it seems to me that Victor's issue is not an indication
>> for those.
>>=20
>> Juergen
>>=20
>>=20
>> ________________________________
>>=20
>> Von: spr...@li... im
>> Auftrag von Thomas Risberg Gesendet: Di 31.08.2004 06:33 An:=20
>> spr...@li... Betreff: Re:=20
>> [Springframework-developer] JTA transaction suspension on WebSphere
>>=20
>>=20
>>=20
>>=20
>> This is not an issue for transactions declared with REQUIRED,
>> SUPPORTS, MANDATORY or NEVER.  For these transactions there is no
>> need to mess with the JTA TransactionManager to suspend the current
>> transaction. UserTransaction is sufficient for these and this
>> should be portable between containers.
>>=20
>> The only trouble is with REQUIRES_NEW and NOT_SUPPORTED.  Here we
>> have to bend the rules and use the JTA TransactionManager API if it
>> is available. This is where things break down since the appservers
>> don't seem to cooperate.  Even WebLogic 8.1 did not work until we
>> used a WebLogic specific API call (forceResume).
>>=20
>> Thomas
>>=20
>>=20
>> Colin Sampaleanu wrote:
>>=20
>>=20
>>=20
>>> Eugene Kuleshov wrote:
>>>=20
>>>=20
>>>=20
>>>> Colin Sampaleanu wrote:
>>>>=20
>>>>=20
>>>>=20
>>>>> 'Eu' on his blog 3-4 days ago commented based on my own blog
>>>>> entry, and a forum message:=20
>>>>> =
http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from
>>>>>  that section / C.2.4 /of the EJB spec says that the
>>>>> container, for EJBs, must implement the UserTransaction
>>>>> interface (and JTA 1.0.1) extension, but doesn't have to
>>>>> implement the other interfaces defined in the JTA
>>>>> specification. Fine, I've actually seen that before,=20
>>>>> coincidentally, when I was tracking something down a while
>>>>> ago, but I think a container is fundamentally broken if it
>>>>> _does_ expose the JTA TransactionManager interface, and it
>>>>> doesn't behave as per the spec. The spec for an API is the
>>>>> spec for the API. If you expose the interface at all, then
>>>>> you need to expose it correctly... That's essentially how I
>>>>> read that clause, and how I see things. In any case, I hope
>>>>> the situation is going to improve, certainly WLS 8 works=20
>>>>> where WLS 7 doesn't, with out WL specific adapter...
>>>>=20
>>>>=20
>>>>=20
>>>> Perhaps I wasn't clear enough. My point is that it is a bad
>>>> idea to mix usage of JTA interface with declarative container
>>>> managed transacttions for EJBs. In other words it is probably
>>>> to use Spring JTA helpers/wrappers in web layer which is not
>>>> using EJB's.
>>>>=20
>>>> Anyway it would be good have some more advanced tests to ensure
>>>> that JTA actually work in WLS8 (and other containers) in case
>>>> of failure/rollback with multiple XA resources involved into
>>>> transaction (especially resources from different vendors, such
>>>> as Oracle, Sybase, MQSeries).
>>>=20
>>>=20
>>> I fully agree about the tests. This is part of the reason I
>>> created the ejbtest integration sample. Hopefully we will keep
>>> adding to it.
>>>=20
>>> As for the clause in question, it says:
>>>=20
>>> "The EJB container must include the JTA 1.0.1 extension, and it
>>> must provide the javax.transaction.UserTransaction interface to
>>> enterprise beans with bean-managed transaction demarcation
>>> through the javax.ejb.EJBContext interface, and also in JNDI
>>> under the name java:comp/UserTransaction, in the cases required
>>> by the EJB specification. The other JTA interfaces are low-level
>>> transaction manager and resource manager integration interfaces,
>>> and are not intended for direct use by enterprise beans.
>>>=20
>>> This is unfortunately not worded very well in my opinion, in
>>> terms of being very clear about CMT. Consider that this is the
>>> section of the spec called 'The Container Provider's
>>> Responsibility'. It is about the minimum set of services which
>>> the container must provide to the EJB. I do not equate anything
>>> in the paragraphs above as saying (with any adequate level of
>>> clarity) that if the container chooses to expose other APIs the=20
>>> EJB _is not_ allowed to use them. I read the last sentence as a=20
>>> justification as to _why_ the container doesn't have to provide
>>> the other JTA interfaces. The spec is actually very specific
>>> about what EJBs may and may not do, consider threading for
>>> example. Again, my opinion is that if the container does choose
>>> to expose an API like JTA's TransactionManager, then it has to
>>> behave correctly, as an API is an API.
>>>=20
>>>=20
>>> Ultimately, only the spec writers know what they really intended,
>>> and I agree that people wanting to move an app from container to
>>> container, and from app server version to version, are not going
>>> to get as predictable results in a CMT+Spring Transaction setup
>>> as they would in a CMT alone, or Spring Tx alone setup. That
>>> said, it can still be a viable and useful combination. Over a
>>> period of some months, I migrated an app on JBoss from CMT EJB to
>>> no EJB with Spring Tx wrapping service beans, and the CMT+Spring
>>> Tx combo provided a valuable middle ground in the migration, in
>>> the perdio when there were still some EJBs, but a lot had already
>>>  moved over.
>>>=20
>>> Regards, Colin




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

Re: [Springframework-developer] JTA transaction suspension on WebSphere

[eu <eu...@md...>]

jürgen höller [werk3AT] wrote:

> That's correct: good point. I'll point that out in the docs.
> 
> My main point was that BEA officially supports the JTA
> TransactionManager interface, so we're allowed to work with it and
> rely on it. That's a good thing and clearly shows BEA's intentions
> (for example, that it should officially work on WebLogic 7 too)!
> However, this admittedly just applies to web components and EJB BMT.
> 
> To the best of my knowledge, *no* JTA work is allowed within EJB CMT:
> neither on the UserTransaction nor on the TransactionManager. Many
> tools violate that principle (for example, Hibernate and JDO when
> registering JTA synchronizations), but that's still what the EJB spec
> says. I'll clarify that in our docs.

   Isn user transaction object available trough bean context wrapper?

> So I recommend to *either* work with EJB CMT *or* Spring-managed
> transactions. Do not try to combine both unless you're aware that
> you're violating the EJB spec. 

   Hey, that was my point! :-)

> However, EJB BMT with Spring-managed
> transactions should work nicely, even if involving the JTA
> TransactionManager on WebLogic.

   I wonder if anyone tested it?
   Anyway using BMT does not have much value, especially with MDB's and 
I believe it will also increase risks of losing data in case of 
container failures/crashes (XA transaction manger use heuristics in this 
case and should roll back everything correctly).

> Unfortunately, I didn't notice earlier that you're working with EJB
> CMT. Does JtaTransactionManager's suspend/resume work with EJB BMT on
> WebLogic 7.0? That is, does that strange NullPointerException in
> WebLogic code occur with BMT too? I assume that Thomas did his tests
> on WebLogic 8.1 (where "forceResume" works) with EJB BMT...

   So, now it is unclear if it does work on WLS 8 in CMT scenario?

   regards,
   Eugene


> -----Original Message----- From:
> spr...@li... 
> [mailto:spr...@li...]On
> Behalf Of Eugene Kuleshov Sent: Thursday, September 02, 2004 1:23 PM 
> To: spr...@li... Cc: Dmitri
> Maximovich Subject: Re: [Springframework-developer] JTA transaction
> suspension on WebSphere
> 
> 
> Juergen,
> 
> If I'm reading this correctly, JTA transaction manager interface in
> Weblogic available to beans that are managing transactions
> themselves, but not suppose to be used by beans under CMT.
> 
> regards, Eugene
> 
> 
> 
>> A further update: I've just discovered that WebLogic even
>> officially supports javax.transaction.TransactionManager as public
>> API!
>> 
>> http://e-docs.bea.com/wls/docs70/jta/jtaapi.html
>> 
>> "Client-initiated transactions-the JTA transaction manager
>> interface (javax.transaction.TransactionManager) is made available
>> to clients and bean providers through JNDI. This allows clients and
>> EJBs using bean-managed transactions to suspend and resume
>> transactions."
>> 
>> They only interpret the semantics of resume a bit differently, i.e.
>> not automatically resuming a transaction that has been marked
>> rollback-only. They explicitly offer their proprietary forceResume
>> method for this. It's quite clearly a bug then that it doesn't work
>> in WebLogic 7.0: We could even try to report that to BEA! It does
>> work in WebLogic 8.1, though...
>> 
>> So in principle, suspend/resume via the JTA TransactionManager *is*
>>  supported by WebLogic, just with special semantics. And if you
>> need the forceResume semantics, you can use Spring's new 
>> WebLogicJtaTransactionManager. Essentially, the JTA spec should be
>> clearer about the semantics of TransactionManager.resume here...
>> 
> 
> 
>> 
>> ________________________________
>> 
>> Von: spr...@li... im
>> Auftrag von jürgen höller [werk3AT] Gesendet: Mi 01.09.2004 22:01
>> An: spr...@li... Betreff: Re: 
>> [Springframework-developer] JTA transaction suspension on WebSphere
>> 
>> 
>> 
>> 
>> An update: The issue was indeed caused by Spring's transaction 
>> synchronization in combination with EJB CMT transaction suspension.
>> Once you turn off Spring's transaction synchronization, which
>> causes our Hibernate support to fall back to direct JTA
>> synchronization, everything works nicely. I've also refined our
>> Hibernate LOB types to be able to work with direct JTA
>> synchronization too, so that our full Hibernate support works in
>> such a scenario without hassle.
>> 
>> Furthermore, Victor was so kind to test a variety of combinations
>> with Spring-driven JTA transaction suspension on WebSphere, among
>> those with an outer transaction that has been marked rollback-only
>> (which doesn't work out-of-the-box on WebLogic). Fortunately,
>> everything worked nicely!
>> 
>> Thus, it's now quite safe to assume that WebSphere's JTA
>> TransactionManager is fully compatible with Spring, at least on
>> WebSphere 4. It would be good to get some tests on WebSphere 5 -
>> any volunteers? This means, to the best of our current knowledge,
>> that we only need special handling (WebLogicJtaTransactionManager)
>> on WebLogic, and that the only container where suspend/resume
>> doesn't work in all cases is WebLogic 7.
>> 
>> Juergen
>> 
>> 
>> ________________________________
>> 
>> Von: spr...@li... im
>> Auftrag von jürgen höller [werk3AT] Gesendet: Di 31.08.2004 10:58
>> An: spr...@li... Betreff: Re: 
>> [Springframework-developer] JTA transaction suspension on WebSphere
>> 
>> 
>> 
>> 
>> Indeed, Thomas: I've pointed out exactly the same to Eugene on that
>>  WebLogic issue in JIRA.
>> 
>> FYI, I've just noticed that I might have misinterpreted Victor's
>> problem last night: He doesn't use Spring transactions with
>> REQUIRES_NEW, but rather an outer Spring transaction plus an inner
>> EJB CMT transaction with REQUIRES_NEW. Spring's
>> JtaTransactionManager never touches the JTA TransactionManager is
>> such a scenario, so it can't be caused by the suspend/resume
>> interaction there.
>> 
>> I rather suspect that the problem is Spring's transaction
>> synchronization, which gets activated for the outer Spring
>> transaction, but doesn't get notified of the transaction suspension
>> caused by the inner EJB CMT transaction. Therefore, Spring's
>> Hibernate support within the inner transaction will still
>> synchronize with the outer Spring transaction, flushing the
>> Hibernate Session at completion of the *outer* rather than the 
>> inner transaction.
>> 
>> The solution I've suggested is to turn off Spring's transaction 
>> synchronization in that case. It should always be turned off when
>> using transaction suspension driven by EJB CMT. See my JIRA
>> comments:
>> 
>> http://opensource.atlassian.com/projects/spring/browse/SPR-295
>> 
>> As I've noted there, it would still be interesting whether
>> Spring-driven JTA transaction suspension works with WebSphere:
>> i.e., a Spring transaction demarcation with REQUIRES_NEW in case of
>> an existing transaction. We might still face problems there, of
>> course, but it seems to me that Victor's issue is not an indication
>> for those.
>> 
>> Juergen
>> 
>> 
>> ________________________________
>> 
>> Von: spr...@li... im
>> Auftrag von Thomas Risberg Gesendet: Di 31.08.2004 06:33 An: 
>> spr...@li... Betreff: Re: 
>> [Springframework-developer] JTA transaction suspension on WebSphere
>> 
>> 
>> 
>> 
>> This is not an issue for transactions declared with REQUIRED,
>> SUPPORTS, MANDATORY or NEVER.  For these transactions there is no
>> need to mess with the JTA TransactionManager to suspend the current
>> transaction. UserTransaction is sufficient for these and this
>> should be portable between containers.
>> 
>> The only trouble is with REQUIRES_NEW and NOT_SUPPORTED.  Here we
>> have to bend the rules and use the JTA TransactionManager API if it
>> is available. This is where things break down since the appservers
>> don't seem to cooperate.  Even WebLogic 8.1 did not work until we
>> used a WebLogic specific API call (forceResume).
>> 
>> Thomas
>> 
>> 
>> Colin Sampaleanu wrote:
>> 
>> 
>> 
>>> Eugene Kuleshov wrote:
>>> 
>>> 
>>> 
>>>> Colin Sampaleanu wrote:
>>>> 
>>>> 
>>>> 
>>>>> 'Eu' on his blog 3-4 days ago commented based on my own blog
>>>>> entry, and a forum message: 
>>>>> http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from
>>>>>  that section / C.2.4 /of the EJB spec says that the
>>>>> container, for EJBs, must implement the UserTransaction
>>>>> interface (and JTA 1.0.1) extension, but doesn't have to
>>>>> implement the other interfaces defined in the JTA
>>>>> specification. Fine, I've actually seen that before, 
>>>>> coincidentally, when I was tracking something down a while
>>>>> ago, but I think a container is fundamentally broken if it
>>>>> _does_ expose the JTA TransactionManager interface, and it
>>>>> doesn't behave as per the spec. The spec for an API is the
>>>>> spec for the API. If you expose the interface at all, then
>>>>> you need to expose it correctly... That's essentially how I
>>>>> read that clause, and how I see things. In any case, I hope
>>>>> the situation is going to improve, certainly WLS 8 works 
>>>>> where WLS 7 doesn't, with out WL specific adapter...
>>>> 
>>>> 
>>>> 
>>>> Perhaps I wasn't clear enough. My point is that it is a bad
>>>> idea to mix usage of JTA interface with declarative container
>>>> managed transacttions for EJBs. In other words it is probably
>>>> to use Spring JTA helpers/wrappers in web layer which is not
>>>> using EJB's.
>>>> 
>>>> Anyway it would be good have some more advanced tests to ensure
>>>> that JTA actually work in WLS8 (and other containers) in case
>>>> of failure/rollback with multiple XA resources involved into
>>>> transaction (especially resources from different vendors, such
>>>> as Oracle, Sybase, MQSeries).
>>> 
>>> 
>>> I fully agree about the tests. This is part of the reason I
>>> created the ejbtest integration sample. Hopefully we will keep
>>> adding to it.
>>> 
>>> As for the clause in question, it says:
>>> 
>>> "The EJB container must include the JTA 1.0.1 extension, and it
>>> must provide the javax.transaction.UserTransaction interface to
>>> enterprise beans with bean-managed transaction demarcation
>>> through the javax.ejb.EJBContext interface, and also in JNDI
>>> under the name java:comp/UserTransaction, in the cases required
>>> by the EJB specification. The other JTA interfaces are low-level
>>> transaction manager and resource manager integration interfaces,
>>> and are not intended for direct use by enterprise beans.
>>> 
>>> This is unfortunately not worded very well in my opinion, in
>>> terms of being very clear about CMT. Consider that this is the
>>> section of the spec called 'The Container Provider's
>>> Responsibility'. It is about the minimum set of services which
>>> the container must provide to the EJB. I do not equate anything
>>> in the paragraphs above as saying (with any adequate level of
>>> clarity) that if the container chooses to expose other APIs the 
>>> EJB _is not_ allowed to use them. I read the last sentence as a 
>>> justification as to _why_ the container doesn't have to provide
>>> the other JTA interfaces. The spec is actually very specific
>>> about what EJBs may and may not do, consider threading for
>>> example. Again, my opinion is that if the container does choose
>>> to expose an API like JTA's TransactionManager, then it has to
>>> behave correctly, as an API is an API.
>>> 
>>> 
>>> Ultimately, only the spec writers know what they really intended,
>>> and I agree that people wanting to move an app from container to
>>> container, and from app server version to version, are not going
>>> to get as predictable results in a CMT+Spring Transaction setup
>>> as they would in a CMT alone, or Spring Tx alone setup. That
>>> said, it can still be a viable and useful combination. Over a
>>> period of some months, I migrated an app on JBoss from CMT EJB to
>>> no EJB with Spring Tx wrapping service beans, and the CMT+Spring
>>> Tx combo provided a valuable middle ground in the migration, in
>>> the perdio when there were still some EJBs, but a lot had already
>>>  moved over.
>>> 
>>> Regards, Colin

Re: [Springframework-developer] =?GB2312?B?v+zAtL+0v7TO0rXEzbXFxA==?= =?GB2312?B?1/fGtw==?=

[Dmitriy K. <dko...@ru...>]

This is not funny ;-)


playearth79 wrote:

> 朋友:
> 你好!
> 我是某五星级酒店的经理,同时我也是一名专拍社会丑恶现象的偷拍爱好者,近年来
> 我在酒店一些高档客房偷偷装上摄像头,偷拍了两百多部作品,里面既有夫妻新婚
> 之夜的
> 夫妻生活片段;也有演艺圈内一些演员为讨好名导演发生的性交易实录;甚至还有
> 一些富
> 豪花高价购买中学女生们初夜权,更为可耻的是居然还是在白天和年仅十五、六
> 岁发育
> 不太成熟的中学小女生发生性关系,因此其丑恶行径拍得更清楚不过了,这些富豪
> 们退房
> 后本人还在其房间拍到了床单上其与中学女生发生性关系留下的鲜红的血迹.为
> 了揭露
> 社会的这些丑恶现象,让这些人接受社会的谴责,本人特开办"中国丑恶现象偷伯
> 网",将
> 本人偷拍到的这些社会丑恶方面的作品公开,希望能得到网友们的支持,如果你也
> 有关于
> 这方面的作品,也可以在本人的网站上发布.
> "中国丑恶现象偷拍网"网址:http://chinaweb.a184.zgsj.com/index.htm, 欢迎访
> 问,希望能得到大家的支持,本网站系公益性网站,无任何广告,偷拍影片全部采用
> asx格
> 式压缩,如果您的系统没有安装解码器,可以在本站在线安装或下载安装即可观赏
> 本人的
> 作品.
> 中国丑恶现象偷伯网

Re: [Springframework-developer] JTA transaction suspension on WebSphere

[Thomas R. <tho...@tr...>]

I was using CMT with 8.1sp2.

Thomas

jürgen höller [werk3AT] wrote:

>Thomas, can you confirm whether you used CMT or BMT in your tests on WebLogic 8.1? If it was BMT, can you check whether you get a strange NullPointerException with CMT, like Eugene gets on WebLogic 7.0?
>
>Eugene, it would be great if you could check whether "forceResume" works with BMT on WebLogic 7.0. We need to document behavior with BMT clearly. Judging from the BEA docs, this should work with BMT; if not, it's WebLogic bug.
>
>>From my point of view, we do not officially support Spring transactions within EJB CMT in the first place, as any use of JTA (no matter whether UserTransaction or TransactionManager) is forbidden within CMT. Correct me if I'm wrong, of course!
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of jürgen höller [werk3AT]
>Sent: Thursday, September 02, 2004 2:58 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] JTA transaction suspension on
>WebSphere
>
>
>That's correct: good point. I'll point that out in the docs.
>
>My main point was that BEA officially supports the JTA TransactionManager interface, so we're allowed to work with it and rely on it. That's a good thing and clearly shows BEA's intentions (for example, that it should officially work on WebLogic 7 too)! However, this admittedly just applies to web components and EJB BMT.
>
>To the best of my knowledge, *no* JTA work is allowed within EJB CMT: neither on the UserTransaction nor on the TransactionManager. Many tools violate that principle (for example, Hibernate and JDO when registering JTA synchronizations), but that's still what the EJB spec says. I'll clarify that in our docs.
>
>So I recommend to *either* work with EJB CMT *or* Spring-managed transactions. Do not try to combine both unless you're aware that you're violating the EJB spec. However, EJB BMT with Spring-managed transactions should work nicely, even if involving the JTA TransactionManager on WebLogic.
>
>Unfortunately, I didn't notice earlier that you're working with EJB CMT. Does JtaTransactionManager's suspend/resume work with EJB BMT on WebLogic 7.0? That is, does that strange NullPointerException in WebLogic code occur with BMT too? I assume that Thomas did his tests on WebLogic 8.1 (where "forceResume" works) with EJB BMT...
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Eugene Kuleshov
>Sent: Thursday, September 02, 2004 1:23 PM
>To: spr...@li...
>Cc: Dmitri Maximovich
>Subject: Re: [Springframework-developer] JTA transaction suspension on
>WebSphere
>
>
>Juergen,
>
>   If I'm reading this correctly, JTA transaction manager interface in Weblogic
>available to beans that are managing transactions themselves, but not suppose
>to be used by beans under CMT.
>
>   regards,
>   Eugene
>
>
>  
>
>>A further update: I've just discovered that WebLogic even officially
>>supports javax.transaction.TransactionManager as public API!
>>
>>http://e-docs.bea.com/wls/docs70/jta/jtaapi.html
>>
>>"Client-initiated transactions-the JTA transaction manager interface
>>(javax.transaction.TransactionManager) is made available to clients and
>>bean providers through JNDI. This allows clients and EJBs using
>>bean-managed transactions to suspend and resume transactions."
>>
>>They only interpret the semantics of resume a bit differently, i.e. not
>>automatically resuming a transaction that has been marked rollback-only.
>>They explicitly offer their proprietary forceResume method for this. It's
>>quite clearly a bug then that it doesn't work in WebLogic 7.0: We could
>>even try to report that to BEA! It does work in WebLogic 8.1, though...
>>
>>So in principle, suspend/resume via the JTA TransactionManager *is*
>>supported by WebLogic, just with special semantics. And if you need the
>>forceResume semantics, you can use Spring's new
>>WebLogicJtaTransactionManager. Essentially, the JTA spec should be clearer
>>about the semantics of TransactionManager.resume here...
>>
>>    
>>
>
>  
>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von
>>jürgen höller [werk3AT] Gesendet: Mi 01.09.2004 22:01 An:
>>spr...@li... Betreff: Re:
>>[Springframework-developer] JTA transaction suspension on WebSphere
>>
>>
>>
>>An update: The issue was indeed caused by Spring's transaction
>>synchronization in combination with EJB CMT transaction suspension. Once
>>you turn off Spring's transaction synchronization, which causes our
>>Hibernate support to fall back to direct JTA synchronization, everything
>>works nicely. I've also refined our Hibernate LOB types to be able to work
>>with direct JTA synchronization too, so that our full Hibernate support
>>works in such a scenario without hassle.
>>
>>Furthermore, Victor was so kind to test a variety of combinations with
>>Spring-driven JTA transaction suspension on WebSphere, among those with an
>>outer transaction that has been marked rollback-only (which doesn't work
>>out-of-the-box on WebLogic). Fortunately, everything worked nicely!
>>
>>Thus, it's now quite safe to assume that WebSphere's JTA TransactionManager
>>is fully compatible with Spring, at least on WebSphere 4. It would be good
>>to get some tests on WebSphere 5 - any volunteers? This means, to the best
>>of our current knowledge, that we only need special handling
>>(WebLogicJtaTransactionManager) on WebLogic, and that the only container
>>where suspend/resume doesn't work in all cases is WebLogic 7.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von
>>jürgen höller [werk3AT] Gesendet: Di 31.08.2004 10:58 An:
>>spr...@li... Betreff: Re:
>>[Springframework-developer] JTA transaction suspension on WebSphere
>>
>>
>>
>>Indeed, Thomas: I've pointed out exactly the same to Eugene on that
>>WebLogic issue in JIRA.
>>
>>FYI, I've just noticed that I might have misinterpreted Victor's problem
>>last night: He doesn't use Spring transactions with REQUIRES_NEW, but
>>rather an outer Spring transaction plus an inner EJB CMT transaction with
>>REQUIRES_NEW. Spring's JtaTransactionManager never touches the JTA
>>TransactionManager is such a scenario, so it can't be caused by the
>>suspend/resume interaction there.
>>
>>I rather suspect that the problem is Spring's transaction synchronization,
>>which gets activated for the outer Spring transaction, but doesn't get
>>notified of the transaction suspension caused by the inner EJB CMT
>>transaction. Therefore, Spring's Hibernate support within the inner
>>transaction will still synchronize with the outer Spring transaction,
>>flushing the Hibernate Session at completion of the *outer* rather than the
>>inner transaction.
>>
>>The solution I've suggested is to turn off Spring's transaction
>>synchronization in that case. It should always be turned off when using
>>transaction suspension driven by EJB CMT. See my JIRA comments:
>>
>>http://opensource.atlassian.com/projects/spring/browse/SPR-295
>>
>>As I've noted there, it would still be interesting whether Spring-driven
>>JTA transaction suspension works with WebSphere: i.e., a Spring transaction
>>demarcation with REQUIRES_NEW in case of an existing transaction. We might
>>still face problems there, of course, but it seems to me that Victor's
>>issue is not an indication for those.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag von
>>Thomas Risberg Gesendet: Di 31.08.2004 06:33 An:
>>spr...@li... Betreff: Re:
>>[Springframework-developer] JTA transaction suspension on WebSphere
>>
>>
>>
>>This is not an issue for transactions declared with REQUIRED, SUPPORTS, 
>>MANDATORY or NEVER.  For these transactions there is no need to mess with
>>the JTA TransactionManager to suspend the current transaction. 
>>UserTransaction is sufficient for these and this should be portable between
>>containers.
>>
>>The only trouble is with REQUIRES_NEW and NOT_SUPPORTED.  Here we have to
>>bend the rules and use the JTA TransactionManager API if it is available.
>>This is where things break down since the appservers don't seem to
>>cooperate.  Even WebLogic 8.1 did not work until we used a WebLogic
>>specific API call (forceResume).
>>
>>Thomas
>>
>>
>>Colin Sampaleanu wrote:
>>
>>
>>    
>>
>>>Eugene Kuleshov wrote:
>>>
>>>
>>>      
>>>
>>>>Colin Sampaleanu wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>'Eu' on his blog 3-4 days ago commented based on my own blog entry, 
>>>>>and a forum message: 
>>>>>http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from 
>>>>>that section / C.2.4 /of the EJB spec says that the container, for 
>>>>>EJBs, must implement the UserTransaction interface (and JTA 1.0.1) 
>>>>>extension, but doesn't have to implement the other interfaces defined
>>>>>in the JTA specification. Fine, I've actually seen that before,
>>>>>coincidentally, when I was tracking something down a while ago, but I
>>>>>think a container is fundamentally broken if it _does_ expose the JTA
>>>>>TransactionManager interface, and it doesn't behave as per the spec.
>>>>>The spec for an API is the spec for the API. If you expose the
>>>>>interface at all, then you need to expose it correctly... That's
>>>>>essentially how I read that clause, and how I see things. In any
>>>>>case, I hope the situation is going to improve, certainly WLS 8 works
>>>>>where WLS 7 doesn't, with out WL specific adapter...
>>>>>          
>>>>>
>>>>
>>>>Perhaps I wasn't clear enough. My point is that it is a bad idea to mix
>>>>usage of JTA interface with declarative container managed transacttions
>>>>for EJBs. In other words it is probably to use Spring JTA
>>>>helpers/wrappers in web layer which is not using EJB's.
>>>>
>>>>Anyway it would be good have some more advanced tests to ensure that
>>>>JTA actually work in WLS8 (and other containers) in case of 
>>>>failure/rollback with multiple XA resources involved into transaction 
>>>>(especially resources from different vendors, such as Oracle, Sybase, 
>>>>MQSeries).
>>>>        
>>>>
>>>I fully agree about the tests. This is part of the reason I created the
>>>ejbtest integration sample. Hopefully we will keep adding to it.
>>>
>>>As for the clause in question, it says:
>>>
>>>"The EJB container must include the JTA 1.0.1 extension, and it must 
>>>provide the javax.transaction.UserTransaction interface to  enterprise 
>>>beans with bean-managed transaction demarcation through the 
>>>javax.ejb.EJBContext interface, and also in JNDI under the name 
>>>java:comp/UserTransaction, in the cases required by the EJB 
>>>specification. The other JTA interfaces are low-level transaction manager
>>>and resource manager integration interfaces, and are not intended for 
>>>direct use by enterprise beans.
>>>
>>>This is unfortunately not worded very well in my opinion, in terms of 
>>>being very clear about CMT. Consider that this is the section of the spec
>>>called 'The Container Provider's Responsibility'. It is about the minimum
>>>set of services which the container must provide to the EJB. I do not
>>>equate anything in the paragraphs above as saying (with any adequate
>>>level of clarity) that if the container chooses to expose other APIs the
>>>EJB _is not_ allowed to use them. I read the last sentence as a
>>>justification as to _why_ the container doesn't have to provide the other
>>>JTA interfaces. The spec is actually very specific about what EJBs may
>>>and may not do, consider threading for example. Again, my opinion is that
>>>if the container does choose to expose an API like JTA's
>>>TransactionManager, then it has to behave correctly, as an API is an API.
>>>
>>>
>>>Ultimately, only the spec writers know what they really intended, and I
>>>agree that people wanting to move an app from container to container, and
>>>from app server version to version, are not going to get as predictable
>>>results in a CMT+Spring Transaction setup as they would in a CMT alone,
>>>or Spring Tx alone setup. That said, it can still be a viable and useful
>>>combination. Over a period of some months, I migrated an app on JBoss
>>>from CMT EJB to no EJB with Spring Tx wrapping service beans, and the
>>>CMT+Spring Tx combo provided a valuable middle ground in the migration,
>>>in the perdio when there were still some EJBs, but a lot had already
>>>moved over.
>>>
>>>Regards, Colin
>>>      
>>>
>
>
>
>-------------------------------------------------------
>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=5047&alloc_id=10808&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>-------------------------------------------------------
>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_idP47&alloc_id808&op=ick
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>-------------------------------------------------------
>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_idP47&alloc_id808&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>  
>

Re: [Springframework-developer] Portlets module and Spring MVC

[William G. T. Jr. <wg...@ru...>]

Nick Lothian wrote:

> Hi,
> 
> Over the last couple of weeks I've spent some time (on & off) doing stuff
> with the Spring Portlets sandbox module. I've read
> <http://opensource.atlassian.com/confluence/spring/display/JSR168/SpringPort
> let+module+design+discussion> and a fair amount of the code.
> 
> I'm finding the Model-Controller part quite nice, and adequately flexible.
> The problem I'm running into is the View part.
> 
> I would like to use the Spring taglibs with the portlet framework, and I've
> done some work to try and get this happening. My impression from the design
> discussion referenced above is that this is the direction it was heading in.

Yes, we would like to see full Spring View technology support for the 
Portlet API and this includes the taglibs.  Did you make 
PortletApplicationContext a subclass of WebApplicationContext?

> 
> I've got it to the point that I believe is known as the 'infamous "Could not
> find Errors instance"'
> (http://article.gmane.org/gmane.comp.java.springframework.user/3863).
> Unfortunately since my controller is a PortletController, the solution isn't
> as straight forward as it should be. Right now I'm trying to fake up a error
> instance manually, and then figure out a better solution when I understand
> it better (Any pointers for some code to do this would be appreciated!).
> 
> Is this the best approach? As a general strategy am I better off altering
> the portlet framework to do things like making a default ThemeResolver
> available etc, or should I be looking at modifying the taglibs to work
> without that stuff?

ThemeResolver is missing since it is expected that the Portal will 
handle these things.  Perhaps the bridge View Servlet could provide a 
mock implementation to satisify the tablibs?

> 
> Is it a realistic goal to get these taglibs working in the portlet
> environment at all?

I think that is still an open question at this point.  We seem to have 
the Views working reasonably well...so I am still hopeful for the tablibs.

later.
Bill


> 
> Nick
> 
> 

[Springframework-developer] Incorrect directory only path matching in PathMatcher

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

http://opensource.atlassian.com/projects/spring/browse/SPR-267

I intend to keep it as-is, following Ant's behavior (as I noted in my =
JIRA comment). Thoughts? Opinions?

Juergen

[Springframework-developer] Status of 303 instead of 302 in RedirectView

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

http://opensource.atlassian.com/projects/spring/browse/SPR-299

I'm not intimately familar with the HTTP spec, so I can't really judge =
this.

A possible compromise could be to just send 303 in case of a POST =
request, and keep sending 302 via response.sendRedirect else. Thoughts? =
Experiences?

Juergen

Re: [Springframework-developer] JTA transaction suspension on WebSphere

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

Thomas, can you confirm whether you used CMT or BMT in your tests on =
WebLogic 8.1? If it was BMT, can you check whether you get a strange =
NullPointerException with CMT, like Eugene gets on WebLogic 7.0?

Eugene, it would be great if you could check whether "forceResume" works =
with BMT on WebLogic 7.0. We need to document behavior with BMT clearly. =
Judging from the BEA docs, this should work with BMT; if not, it's =
WebLogic bug.

From my point of view, we do not officially support Spring transactions =
within EJB CMT in the first place, as any use of JTA (no matter whether =
UserTransaction or TransactionManager) is forbidden within CMT. Correct =
me if I'm wrong, of course!

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Thursday, September 02, 2004 2:58 PM
To: spr...@li...
Subject: Re: [Springframework-developer] JTA transaction suspension on
WebSphere


That's correct: good point. I'll point that out in the docs.

My main point was that BEA officially supports the JTA =
TransactionManager interface, so we're allowed to work with it and rely =
on it. That's a good thing and clearly shows BEA's intentions (for =
example, that it should officially work on WebLogic 7 too)! However, =
this admittedly just applies to web components and EJB BMT.

To the best of my knowledge, *no* JTA work is allowed within EJB CMT: =
neither on the UserTransaction nor on the TransactionManager. Many tools =
violate that principle (for example, Hibernate and JDO when registering =
JTA synchronizations), but that's still what the EJB spec says. I'll =
clarify that in our docs.

So I recommend to *either* work with EJB CMT *or* Spring-managed =
transactions. Do not try to combine both unless you're aware that you're =
violating the EJB spec. However, EJB BMT with Spring-managed =
transactions should work nicely, even if involving the JTA =
TransactionManager on WebLogic.

Unfortunately, I didn't notice earlier that you're working with EJB CMT. =
Does JtaTransactionManager's suspend/resume work with EJB BMT on =
WebLogic 7.0? That is, does that strange NullPointerException in =
WebLogic code occur with BMT too? I assume that Thomas did his tests on =
WebLogic 8.1 (where "forceResume" works) with EJB BMT...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Eugene Kuleshov
Sent: Thursday, September 02, 2004 1:23 PM
To: spr...@li...
Cc: Dmitri Maximovich
Subject: Re: [Springframework-developer] JTA transaction suspension on
WebSphere


Juergen,

   If I'm reading this correctly, JTA transaction manager interface in =
Weblogic
available to beans that are managing transactions themselves, but not =
suppose
to be used by beans under CMT.

   regards,
   Eugene


> A further update: I've just discovered that WebLogic even officially
> supports javax.transaction.TransactionManager as public API!
>=20
> http://e-docs.bea.com/wls/docs70/jta/jtaapi.html
>=20
> "Client-initiated transactions-the JTA transaction manager interface
> (javax.transaction.TransactionManager) is made available to clients =
and
> bean providers through JNDI. This allows clients and EJBs using
> bean-managed transactions to suspend and resume transactions."
>=20
> They only interpret the semantics of resume a bit differently, i.e. =
not
> automatically resuming a transaction that has been marked =
rollback-only.
> They explicitly offer their proprietary forceResume method for this. =
It's
> quite clearly a bug then that it doesn't work in WebLogic 7.0: We =
could
> even try to report that to BEA! It does work in WebLogic 8.1, =
though...
>=20
> So in principle, suspend/resume via the JTA TransactionManager *is*
> supported by WebLogic, just with special semantics. And if you need =
the
> forceResume semantics, you can use Spring's new
> WebLogicJtaTransactionManager. Essentially, the JTA spec should be =
clearer
> about the semantics of TransactionManager.resume here...
>=20

>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag =
von
> j=FCrgen h=F6ller [werk3AT] Gesendet: Mi 01.09.2004 22:01 An:
> spr...@li... Betreff: Re:
> [Springframework-developer] JTA transaction suspension on WebSphere
>=20
>=20
>=20
> An update: The issue was indeed caused by Spring's transaction
> synchronization in combination with EJB CMT transaction suspension. =
Once
> you turn off Spring's transaction synchronization, which causes our
> Hibernate support to fall back to direct JTA synchronization, =
everything
> works nicely. I've also refined our Hibernate LOB types to be able to =
work
> with direct JTA synchronization too, so that our full Hibernate =
support
> works in such a scenario without hassle.
>=20
> Furthermore, Victor was so kind to test a variety of combinations with
> Spring-driven JTA transaction suspension on WebSphere, among those =
with an
> outer transaction that has been marked rollback-only (which doesn't =
work
> out-of-the-box on WebLogic). Fortunately, everything worked nicely!
>=20
> Thus, it's now quite safe to assume that WebSphere's JTA =
TransactionManager
> is fully compatible with Spring, at least on WebSphere 4. It would be =
good
> to get some tests on WebSphere 5 - any volunteers? This means, to the =
best
> of our current knowledge, that we only need special handling
> (WebLogicJtaTransactionManager) on WebLogic, and that the only =
container
> where suspend/resume doesn't work in all cases is WebLogic 7.
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag =
von
> j=FCrgen h=F6ller [werk3AT] Gesendet: Di 31.08.2004 10:58 An:
> spr...@li... Betreff: Re:
> [Springframework-developer] JTA transaction suspension on WebSphere
>=20
>=20
>=20
> Indeed, Thomas: I've pointed out exactly the same to Eugene on that
> WebLogic issue in JIRA.
>=20
> FYI, I've just noticed that I might have misinterpreted Victor's =
problem
> last night: He doesn't use Spring transactions with REQUIRES_NEW, but
> rather an outer Spring transaction plus an inner EJB CMT transaction =
with
> REQUIRES_NEW. Spring's JtaTransactionManager never touches the JTA
> TransactionManager is such a scenario, so it can't be caused by the
> suspend/resume interaction there.
>=20
> I rather suspect that the problem is Spring's transaction =
synchronization,
> which gets activated for the outer Spring transaction, but doesn't get
> notified of the transaction suspension caused by the inner EJB CMT
> transaction. Therefore, Spring's Hibernate support within the inner
> transaction will still synchronize with the outer Spring transaction,
> flushing the Hibernate Session at completion of the *outer* rather =
than the
> inner transaction.
>=20
> The solution I've suggested is to turn off Spring's transaction
> synchronization in that case. It should always be turned off when =
using
> transaction suspension driven by EJB CMT. See my JIRA comments:
>=20
> http://opensource.atlassian.com/projects/spring/browse/SPR-295
>=20
> As I've noted there, it would still be interesting whether =
Spring-driven
> JTA transaction suspension works with WebSphere: i.e., a Spring =
transaction
> demarcation with REQUIRES_NEW in case of an existing transaction. We =
might
> still face problems there, of course, but it seems to me that Victor's
> issue is not an indication for those.
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag =
von
> Thomas Risberg Gesendet: Di 31.08.2004 06:33 An:
> spr...@li... Betreff: Re:
> [Springframework-developer] JTA transaction suspension on WebSphere
>=20
>=20
>=20
> This is not an issue for transactions declared with REQUIRED, =
SUPPORTS,=20
> MANDATORY or NEVER.  For these transactions there is no need to mess =
with
> the JTA TransactionManager to suspend the current transaction.=20
> UserTransaction is sufficient for these and this should be portable =
between
> containers.
>=20
> The only trouble is with REQUIRES_NEW and NOT_SUPPORTED.  Here we have =
to
> bend the rules and use the JTA TransactionManager API if it is =
available.
> This is where things break down since the appservers don't seem to
> cooperate.  Even WebLogic 8.1 did not work until we used a WebLogic
> specific API call (forceResume).
>=20
> Thomas
>=20
>=20
> Colin Sampaleanu wrote:
>=20
>=20
>> Eugene Kuleshov wrote:
>>=20
>>=20
>>> Colin Sampaleanu wrote:
>>>=20
>>>=20
>>>> 'Eu' on his blog 3-4 days ago commented based on my own blog entry, =

>>>> and a forum message:=20
>>>> =
http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from=20
>>>> that section / C.2.4 /of the EJB spec says that the container, for=20
>>>> EJBs, must implement the UserTransaction interface (and JTA 1.0.1)=20
>>>> extension, but doesn't have to implement the other interfaces =
defined
>>>> in the JTA specification. Fine, I've actually seen that before,
>>>> coincidentally, when I was tracking something down a while ago, but =
I
>>>> think a container is fundamentally broken if it _does_ expose the =
JTA
>>>> TransactionManager interface, and it doesn't behave as per the =
spec.
>>>> The spec for an API is the spec for the API. If you expose the
>>>> interface at all, then you need to expose it correctly... That's
>>>> essentially how I read that clause, and how I see things. In any
>>>> case, I hope the situation is going to improve, certainly WLS 8 =
works
>>>> where WLS 7 doesn't, with out WL specific adapter...
>>>=20
>>>=20
>>>=20
>>> Perhaps I wasn't clear enough. My point is that it is a bad idea to =
mix
>>> usage of JTA interface with declarative container managed =
transacttions
>>> for EJBs. In other words it is probably to use Spring JTA
>>> helpers/wrappers in web layer which is not using EJB's.
>>>=20
>>> Anyway it would be good have some more advanced tests to ensure that
>>> JTA actually work in WLS8 (and other containers) in case of=20
>>> failure/rollback with multiple XA resources involved into =
transaction=20
>>> (especially resources from different vendors, such as Oracle, =
Sybase,=20
>>> MQSeries).
>>=20
>>=20
>> I fully agree about the tests. This is part of the reason I created =
the
>> ejbtest integration sample. Hopefully we will keep adding to it.
>>=20
>> As for the clause in question, it says:
>>=20
>> "The EJB container must include the JTA 1.0.1 extension, and it must=20
>> provide the javax.transaction.UserTransaction interface to  =
enterprise=20
>> beans with bean-managed transaction demarcation through the=20
>> javax.ejb.EJBContext interface, and also in JNDI under the name=20
>> java:comp/UserTransaction, in the cases required by the EJB=20
>> specification. The other JTA interfaces are low-level transaction =
manager
>> and resource manager integration interfaces, and are not intended for =

>> direct use by enterprise beans.
>>=20
>> This is unfortunately not worded very well in my opinion, in terms of =

>> being very clear about CMT. Consider that this is the section of the =
spec
>> called 'The Container Provider's Responsibility'. It is about the =
minimum
>> set of services which the container must provide to the EJB. I do not
>> equate anything in the paragraphs above as saying (with any adequate
>> level of clarity) that if the container chooses to expose other APIs =
the
>> EJB _is not_ allowed to use them. I read the last sentence as a
>> justification as to _why_ the container doesn't have to provide the =
other
>> JTA interfaces. The spec is actually very specific about what EJBs =
may
>> and may not do, consider threading for example. Again, my opinion is =
that
>> if the container does choose to expose an API like JTA's
>> TransactionManager, then it has to behave correctly, as an API is an =
API.
>>=20
>>=20
>> Ultimately, only the spec writers know what they really intended, and =
I
>> agree that people wanting to move an app from container to container, =
and
>> from app server version to version, are not going to get as =
predictable
>> results in a CMT+Spring Transaction setup as they would in a CMT =
alone,
>> or Spring Tx alone setup. That said, it can still be a viable and =
useful
>> combination. Over a period of some months, I migrated an app on JBoss
>> from CMT EJB to no EJB with Spring Tx wrapping service beans, and the
>> CMT+Spring Tx combo provided a valuable middle ground in the =
migration,
>> in the perdio when there were still some EJBs, but a lot had already
>> moved over.
>>=20
>> Regards, Colin



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


-------------------------------------------------------
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_idP47&alloc_id=10808&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] JTA transaction suspension on WebSphere

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

That's correct: good point. I'll point that out in the docs.

My main point was that BEA officially supports the JTA =
TransactionManager interface, so we're allowed to work with it and rely =
on it. That's a good thing and clearly shows BEA's intentions (for =
example, that it should officially work on WebLogic 7 too)! However, =
this admittedly just applies to web components and EJB BMT.

To the best of my knowledge, *no* JTA work is allowed within EJB CMT: =
neither on the UserTransaction nor on the TransactionManager. Many tools =
violate that principle (for example, Hibernate and JDO when registering =
JTA synchronizations), but that's still what the EJB spec says. I'll =
clarify that in our docs.

So I recommend to *either* work with EJB CMT *or* Spring-managed =
transactions. Do not try to combine both unless you're aware that you're =
violating the EJB spec. However, EJB BMT with Spring-managed =
transactions should work nicely, even if involving the JTA =
TransactionManager on WebLogic.

Unfortunately, I didn't notice earlier that you're working with EJB CMT. =
Does JtaTransactionManager's suspend/resume work with EJB BMT on =
WebLogic 7.0? That is, does that strange NullPointerException in =
WebLogic code occur with BMT too? I assume that Thomas did his tests on =
WebLogic 8.1 (where "forceResume" works) with EJB BMT...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Eugene Kuleshov
Sent: Thursday, September 02, 2004 1:23 PM
To: spr...@li...
Cc: Dmitri Maximovich
Subject: Re: [Springframework-developer] JTA transaction suspension on
WebSphere


Juergen,

   If I'm reading this correctly, JTA transaction manager interface in =
Weblogic
available to beans that are managing transactions themselves, but not =
suppose
to be used by beans under CMT.

   regards,
   Eugene


> A further update: I've just discovered that WebLogic even officially
> supports javax.transaction.TransactionManager as public API!
>=20
> http://e-docs.bea.com/wls/docs70/jta/jtaapi.html
>=20
> "Client-initiated transactions-the JTA transaction manager interface
> (javax.transaction.TransactionManager) is made available to clients =
and
> bean providers through JNDI. This allows clients and EJBs using
> bean-managed transactions to suspend and resume transactions."
>=20
> They only interpret the semantics of resume a bit differently, i.e. =
not
> automatically resuming a transaction that has been marked =
rollback-only.
> They explicitly offer their proprietary forceResume method for this. =
It's
> quite clearly a bug then that it doesn't work in WebLogic 7.0: We =
could
> even try to report that to BEA! It does work in WebLogic 8.1, =
though...
>=20
> So in principle, suspend/resume via the JTA TransactionManager *is*
> supported by WebLogic, just with special semantics. And if you need =
the
> forceResume semantics, you can use Spring's new
> WebLogicJtaTransactionManager. Essentially, the JTA spec should be =
clearer
> about the semantics of TransactionManager.resume here...
>=20

>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag =
von
> j=FCrgen h=F6ller [werk3AT] Gesendet: Mi 01.09.2004 22:01 An:
> spr...@li... Betreff: Re:
> [Springframework-developer] JTA transaction suspension on WebSphere
>=20
>=20
>=20
> An update: The issue was indeed caused by Spring's transaction
> synchronization in combination with EJB CMT transaction suspension. =
Once
> you turn off Spring's transaction synchronization, which causes our
> Hibernate support to fall back to direct JTA synchronization, =
everything
> works nicely. I've also refined our Hibernate LOB types to be able to =
work
> with direct JTA synchronization too, so that our full Hibernate =
support
> works in such a scenario without hassle.
>=20
> Furthermore, Victor was so kind to test a variety of combinations with
> Spring-driven JTA transaction suspension on WebSphere, among those =
with an
> outer transaction that has been marked rollback-only (which doesn't =
work
> out-of-the-box on WebLogic). Fortunately, everything worked nicely!
>=20
> Thus, it's now quite safe to assume that WebSphere's JTA =
TransactionManager
> is fully compatible with Spring, at least on WebSphere 4. It would be =
good
> to get some tests on WebSphere 5 - any volunteers? This means, to the =
best
> of our current knowledge, that we only need special handling
> (WebLogicJtaTransactionManager) on WebLogic, and that the only =
container
> where suspend/resume doesn't work in all cases is WebLogic 7.
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag =
von
> j=FCrgen h=F6ller [werk3AT] Gesendet: Di 31.08.2004 10:58 An:
> spr...@li... Betreff: Re:
> [Springframework-developer] JTA transaction suspension on WebSphere
>=20
>=20
>=20
> Indeed, Thomas: I've pointed out exactly the same to Eugene on that
> WebLogic issue in JIRA.
>=20
> FYI, I've just noticed that I might have misinterpreted Victor's =
problem
> last night: He doesn't use Spring transactions with REQUIRES_NEW, but
> rather an outer Spring transaction plus an inner EJB CMT transaction =
with
> REQUIRES_NEW. Spring's JtaTransactionManager never touches the JTA
> TransactionManager is such a scenario, so it can't be caused by the
> suspend/resume interaction there.
>=20
> I rather suspect that the problem is Spring's transaction =
synchronization,
> which gets activated for the outer Spring transaction, but doesn't get
> notified of the transaction suspension caused by the inner EJB CMT
> transaction. Therefore, Spring's Hibernate support within the inner
> transaction will still synchronize with the outer Spring transaction,
> flushing the Hibernate Session at completion of the *outer* rather =
than the
> inner transaction.
>=20
> The solution I've suggested is to turn off Spring's transaction
> synchronization in that case. It should always be turned off when =
using
> transaction suspension driven by EJB CMT. See my JIRA comments:
>=20
> http://opensource.atlassian.com/projects/spring/browse/SPR-295
>=20
> As I've noted there, it would still be interesting whether =
Spring-driven
> JTA transaction suspension works with WebSphere: i.e., a Spring =
transaction
> demarcation with REQUIRES_NEW in case of an existing transaction. We =
might
> still face problems there, of course, but it seems to me that Victor's
> issue is not an indication for those.
>=20
> Juergen
>=20
>=20
> ________________________________
>=20
> Von: spr...@li... im Auftrag =
von
> Thomas Risberg Gesendet: Di 31.08.2004 06:33 An:
> spr...@li... Betreff: Re:
> [Springframework-developer] JTA transaction suspension on WebSphere
>=20
>=20
>=20
> This is not an issue for transactions declared with REQUIRED, =
SUPPORTS,=20
> MANDATORY or NEVER.  For these transactions there is no need to mess =
with
> the JTA TransactionManager to suspend the current transaction.=20
> UserTransaction is sufficient for these and this should be portable =
between
> containers.
>=20
> The only trouble is with REQUIRES_NEW and NOT_SUPPORTED.  Here we have =
to
> bend the rules and use the JTA TransactionManager API if it is =
available.
> This is where things break down since the appservers don't seem to
> cooperate.  Even WebLogic 8.1 did not work until we used a WebLogic
> specific API call (forceResume).
>=20
> Thomas
>=20
>=20
> Colin Sampaleanu wrote:
>=20
>=20
>> Eugene Kuleshov wrote:
>>=20
>>=20
>>> Colin Sampaleanu wrote:
>>>=20
>>>=20
>>>> 'Eu' on his blog 3-4 days ago commented based on my own blog entry, =

>>>> and a forum message:=20
>>>> =
http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from=20
>>>> that section / C.2.4 /of the EJB spec says that the container, for=20
>>>> EJBs, must implement the UserTransaction interface (and JTA 1.0.1)=20
>>>> extension, but doesn't have to implement the other interfaces =
defined
>>>> in the JTA specification. Fine, I've actually seen that before,
>>>> coincidentally, when I was tracking something down a while ago, but =
I
>>>> think a container is fundamentally broken if it _does_ expose the =
JTA
>>>> TransactionManager interface, and it doesn't behave as per the =
spec.
>>>> The spec for an API is the spec for the API. If you expose the
>>>> interface at all, then you need to expose it correctly... That's
>>>> essentially how I read that clause, and how I see things. In any
>>>> case, I hope the situation is going to improve, certainly WLS 8 =
works
>>>> where WLS 7 doesn't, with out WL specific adapter...
>>>=20
>>>=20
>>>=20
>>> Perhaps I wasn't clear enough. My point is that it is a bad idea to =
mix
>>> usage of JTA interface with declarative container managed =
transacttions
>>> for EJBs. In other words it is probably to use Spring JTA
>>> helpers/wrappers in web layer which is not using EJB's.
>>>=20
>>> Anyway it would be good have some more advanced tests to ensure that
>>> JTA actually work in WLS8 (and other containers) in case of=20
>>> failure/rollback with multiple XA resources involved into =
transaction=20
>>> (especially resources from different vendors, such as Oracle, =
Sybase,=20
>>> MQSeries).
>>=20
>>=20
>> I fully agree about the tests. This is part of the reason I created =
the
>> ejbtest integration sample. Hopefully we will keep adding to it.
>>=20
>> As for the clause in question, it says:
>>=20
>> "The EJB container must include the JTA 1.0.1 extension, and it must=20
>> provide the javax.transaction.UserTransaction interface to  =
enterprise=20
>> beans with bean-managed transaction demarcation through the=20
>> javax.ejb.EJBContext interface, and also in JNDI under the name=20
>> java:comp/UserTransaction, in the cases required by the EJB=20
>> specification. The other JTA interfaces are low-level transaction =
manager
>> and resource manager integration interfaces, and are not intended for =

>> direct use by enterprise beans.
>>=20
>> This is unfortunately not worded very well in my opinion, in terms of =

>> being very clear about CMT. Consider that this is the section of the =
spec
>> called 'The Container Provider's Responsibility'. It is about the =
minimum
>> set of services which the container must provide to the EJB. I do not
>> equate anything in the paragraphs above as saying (with any adequate
>> level of clarity) that if the container chooses to expose other APIs =
the
>> EJB _is not_ allowed to use them. I read the last sentence as a
>> justification as to _why_ the container doesn't have to provide the =
other
>> JTA interfaces. The spec is actually very specific about what EJBs =
may
>> and may not do, consider threading for example. Again, my opinion is =
that
>> if the container does choose to expose an API like JTA's
>> TransactionManager, then it has to behave correctly, as an API is an =
API.
>>=20
>>=20
>> Ultimately, only the spec writers know what they really intended, and =
I
>> agree that people wanting to move an app from container to container, =
and
>> from app server version to version, are not going to get as =
predictable
>> results in a CMT+Spring Transaction setup as they would in a CMT =
alone,
>> or Spring Tx alone setup. That said, it can still be a viable and =
useful
>> combination. Over a period of some months, I migrated an app on JBoss
>> from CMT EJB to no EJB with Spring Tx wrapping service beans, and the
>> CMT+Spring Tx combo provided a valuable middle ground in the =
migration,
>> in the perdio when there were still some EJBs, but a lot had already
>> moved over.
>>=20
>> Regards, Colin



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

Re: [Springframework-developer] Portlets and Spring

[William G. T. Jr. <wg...@ru...>]

Cameron Zemek wrote:
> Is there any efforts to provide a framework for Portlet development in Spring?

Yes, there is a package in the sandbox the provides PortletMVC similar 
to Spring WebMVC and follows the design outlined here:
http://opensource.atlassian.com/confluence/spring/display/JSR168/SpringPortlet+module+design+discussion

There has also been much dicussion on the list:
http://search.gmane.org/search.php?group=gmane.comp.java.springframework.devel&query=portlet

To get started quickly, check this post out:
https://list.unm.edu/cgi-bin/wa?A2=ind0405&L=jasig-dev&P=R2654

later.
Bill

[Springframework-developer] Portlets and Spring

[Cameron Z. <gro...@ya...>]

Is there any efforts to provide a framework for Portlet development in Spring?

Re: [Springframework-developer] JTA transaction suspension on WebSphere

[Eugene K. <eu...@pl...>]

Juergen,

   If I'm reading this correctly, JTA transaction manager interface in Weblogic
available to beans that are managing transactions themselves, but not suppose
to be used by beans under CMT.

   regards,
   Eugene


> A further update: I've just discovered that WebLogic even officially
> supports javax.transaction.TransactionManager as public API!
> 
> http://e-docs.bea.com/wls/docs70/jta/jtaapi.html
> 
> "Client-initiated transactions-the JTA transaction manager interface
> (javax.transaction.TransactionManager) is made available to clients and
> bean providers through JNDI. This allows clients and EJBs using
> bean-managed transactions to suspend and resume transactions."
> 
> They only interpret the semantics of resume a bit differently, i.e. not
> automatically resuming a transaction that has been marked rollback-only.
> They explicitly offer their proprietary forceResume method for this. It's
> quite clearly a bug then that it doesn't work in WebLogic 7.0: We could
> even try to report that to BEA! It does work in WebLogic 8.1, though...
> 
> So in principle, suspend/resume via the JTA TransactionManager *is*
> supported by WebLogic, just with special semantics. And if you need the
> forceResume semantics, you can use Spring's new
> WebLogicJtaTransactionManager. Essentially, the JTA spec should be clearer
> about the semantics of TransactionManager.resume here...
> 

> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von
> jürgen höller [werk3AT] Gesendet: Mi 01.09.2004 22:01 An:
> spr...@li... Betreff: Re:
> [Springframework-developer] JTA transaction suspension on WebSphere
> 
> 
> 
> An update: The issue was indeed caused by Spring's transaction
> synchronization in combination with EJB CMT transaction suspension. Once
> you turn off Spring's transaction synchronization, which causes our
> Hibernate support to fall back to direct JTA synchronization, everything
> works nicely. I've also refined our Hibernate LOB types to be able to work
> with direct JTA synchronization too, so that our full Hibernate support
> works in such a scenario without hassle.
> 
> Furthermore, Victor was so kind to test a variety of combinations with
> Spring-driven JTA transaction suspension on WebSphere, among those with an
> outer transaction that has been marked rollback-only (which doesn't work
> out-of-the-box on WebLogic). Fortunately, everything worked nicely!
> 
> Thus, it's now quite safe to assume that WebSphere's JTA TransactionManager
> is fully compatible with Spring, at least on WebSphere 4. It would be good
> to get some tests on WebSphere 5 - any volunteers? This means, to the best
> of our current knowledge, that we only need special handling
> (WebLogicJtaTransactionManager) on WebLogic, and that the only container
> where suspend/resume doesn't work in all cases is WebLogic 7.
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von
> jürgen höller [werk3AT] Gesendet: Di 31.08.2004 10:58 An:
> spr...@li... Betreff: Re:
> [Springframework-developer] JTA transaction suspension on WebSphere
> 
> 
> 
> Indeed, Thomas: I've pointed out exactly the same to Eugene on that
> WebLogic issue in JIRA.
> 
> FYI, I've just noticed that I might have misinterpreted Victor's problem
> last night: He doesn't use Spring transactions with REQUIRES_NEW, but
> rather an outer Spring transaction plus an inner EJB CMT transaction with
> REQUIRES_NEW. Spring's JtaTransactionManager never touches the JTA
> TransactionManager is such a scenario, so it can't be caused by the
> suspend/resume interaction there.
> 
> I rather suspect that the problem is Spring's transaction synchronization,
> which gets activated for the outer Spring transaction, but doesn't get
> notified of the transaction suspension caused by the inner EJB CMT
> transaction. Therefore, Spring's Hibernate support within the inner
> transaction will still synchronize with the outer Spring transaction,
> flushing the Hibernate Session at completion of the *outer* rather than the
> inner transaction.
> 
> The solution I've suggested is to turn off Spring's transaction
> synchronization in that case. It should always be turned off when using
> transaction suspension driven by EJB CMT. See my JIRA comments:
> 
> http://opensource.atlassian.com/projects/spring/browse/SPR-295
> 
> As I've noted there, it would still be interesting whether Spring-driven
> JTA transaction suspension works with WebSphere: i.e., a Spring transaction
> demarcation with REQUIRES_NEW in case of an existing transaction. We might
> still face problems there, of course, but it seems to me that Victor's
> issue is not an indication for those.
> 
> Juergen
> 
> 
> ________________________________
> 
> Von: spr...@li... im Auftrag von
> Thomas Risberg Gesendet: Di 31.08.2004 06:33 An:
> spr...@li... Betreff: Re:
> [Springframework-developer] JTA transaction suspension on WebSphere
> 
> 
> 
> This is not an issue for transactions declared with REQUIRED, SUPPORTS, 
> MANDATORY or NEVER.  For these transactions there is no need to mess with
> the JTA TransactionManager to suspend the current transaction. 
> UserTransaction is sufficient for these and this should be portable between
> containers.
> 
> The only trouble is with REQUIRES_NEW and NOT_SUPPORTED.  Here we have to
> bend the rules and use the JTA TransactionManager API if it is available.
> This is where things break down since the appservers don't seem to
> cooperate.  Even WebLogic 8.1 did not work until we used a WebLogic
> specific API call (forceResume).
> 
> Thomas
> 
> 
> Colin Sampaleanu wrote:
> 
> 
>> Eugene Kuleshov wrote:
>> 
>> 
>>> Colin Sampaleanu wrote:
>>> 
>>> 
>>>> 'Eu' on his blog 3-4 days ago commented based on my own blog entry, 
>>>> and a forum message: 
>>>> http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from 
>>>> that section / C.2.4 /of the EJB spec says that the container, for 
>>>> EJBs, must implement the UserTransaction interface (and JTA 1.0.1) 
>>>> extension, but doesn't have to implement the other interfaces defined
>>>> in the JTA specification. Fine, I've actually seen that before,
>>>> coincidentally, when I was tracking something down a while ago, but I
>>>> think a container is fundamentally broken if it _does_ expose the JTA
>>>> TransactionManager interface, and it doesn't behave as per the spec.
>>>> The spec for an API is the spec for the API. If you expose the
>>>> interface at all, then you need to expose it correctly... That's
>>>> essentially how I read that clause, and how I see things. In any
>>>> case, I hope the situation is going to improve, certainly WLS 8 works
>>>> where WLS 7 doesn't, with out WL specific adapter...
>>> 
>>> 
>>> 
>>> Perhaps I wasn't clear enough. My point is that it is a bad idea to mix
>>> usage of JTA interface with declarative container managed transacttions
>>> for EJBs. In other words it is probably to use Spring JTA
>>> helpers/wrappers in web layer which is not using EJB's.
>>> 
>>> Anyway it would be good have some more advanced tests to ensure that
>>> JTA actually work in WLS8 (and other containers) in case of 
>>> failure/rollback with multiple XA resources involved into transaction 
>>> (especially resources from different vendors, such as Oracle, Sybase, 
>>> MQSeries).
>> 
>> 
>> I fully agree about the tests. This is part of the reason I created the
>> ejbtest integration sample. Hopefully we will keep adding to it.
>> 
>> As for the clause in question, it says:
>> 
>> "The EJB container must include the JTA 1.0.1 extension, and it must 
>> provide the javax.transaction.UserTransaction interface to  enterprise 
>> beans with bean-managed transaction demarcation through the 
>> javax.ejb.EJBContext interface, and also in JNDI under the name 
>> java:comp/UserTransaction, in the cases required by the EJB 
>> specification. The other JTA interfaces are low-level transaction manager
>> and resource manager integration interfaces, and are not intended for 
>> direct use by enterprise beans.
>> 
>> This is unfortunately not worded very well in my opinion, in terms of 
>> being very clear about CMT. Consider that this is the section of the spec
>> called 'The Container Provider's Responsibility'. It is about the minimum
>> set of services which the container must provide to the EJB. I do not
>> equate anything in the paragraphs above as saying (with any adequate
>> level of clarity) that if the container chooses to expose other APIs the
>> EJB _is not_ allowed to use them. I read the last sentence as a
>> justification as to _why_ the container doesn't have to provide the other
>> JTA interfaces. The spec is actually very specific about what EJBs may
>> and may not do, consider threading for example. Again, my opinion is that
>> if the container does choose to expose an API like JTA's
>> TransactionManager, then it has to behave correctly, as an API is an API.
>> 
>> 
>> Ultimately, only the spec writers know what they really intended, and I
>> agree that people wanting to move an app from container to container, and
>> from app server version to version, are not going to get as predictable
>> results in a CMT+Spring Transaction setup as they would in a CMT alone,
>> or Spring Tx alone setup. That said, it can still be a viable and useful
>> combination. Over a period of some months, I migrated an app on JBoss
>> from CMT EJB to no EJB with Spring Tx wrapping service beans, and the
>> CMT+Spring Tx combo provided a valuable middle ground in the migration,
>> in the perdio when there were still some EJBs, but a lot had already
>> moved over.
>> 
>> Regards, Colin

Re: [Springframework-developer] JTA transaction suspension on WebSphere

[Colin S. <col...@ex...>]

Too bad they don't go as far as saying it's kosher to use it with CMT 
though :-)

jürgen höller [werk3AT] wrote:

>A further update: I've just discovered that WebLogic even officially supports javax.transaction.TransactionManager as public API!
> 
>http://e-docs.bea.com/wls/docs70/jta/jtaapi.html
> 
>"Client-initiated transactions-the JTA transaction manager interface (javax.transaction.TransactionManager) is made available to clients and bean providers through JNDI. This allows clients and EJBs using bean-managed transactions to suspend and resume transactions."
> 
>They only interpret the semantics of resume a bit differently, i.e. not automatically resuming a transaction that has been marked rollback-only. They explicitly offer their proprietary forceResume method for this. It's quite clearly a bug then that it doesn't work in WebLogic 7.0: We could even try to report that to BEA! It does work in WebLogic 8.1, though...
> 
>So in principle, suspend/resume via the JTA TransactionManager *is* supported by WebLogic, just with special semantics. And if you need the forceResume semantics, you can use Spring's new WebLogicJtaTransactionManager. Essentially, the JTA spec should be clearer about the semantics of TransactionManager.resume here...
>
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
>Gesendet: Mi 01.09.2004 22:01
>An: spr...@li...
>Betreff: Re: [Springframework-developer] JTA transaction suspension on WebSphere
>
>
>
>An update: The issue was indeed caused by Spring's transaction synchronization in combination with EJB CMT transaction suspension. Once you turn off Spring's transaction synchronization, which causes our Hibernate support to fall back to direct JTA synchronization, everything works nicely. I've also refined our Hibernate LOB types to be able to work with direct JTA synchronization too, so that our full Hibernate support works in such a scenario without hassle.
>
>Furthermore, Victor was so kind to test a variety of combinations with Spring-driven JTA transaction suspension on WebSphere, among those with an outer transaction that has been marked rollback-only (which doesn't work out-of-the-box on WebLogic). Fortunately, everything worked nicely!
>
>Thus, it's now quite safe to assume that WebSphere's JTA TransactionManager is fully compatible with Spring, at least on WebSphere 4. It would be good to get some tests on WebSphere 5 - any volunteers? This means, to the best of our current knowledge, that we only need special handling (WebLogicJtaTransactionManager) on WebLogic, and that the only container where suspend/resume doesn't work in all cases is WebLogic 7.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
>Gesendet: Di 31.08.2004 10:58
>An: spr...@li...
>Betreff: Re: [Springframework-developer] JTA transaction suspension on WebSphere
>
>
>
>Indeed, Thomas: I've pointed out exactly the same to Eugene on that WebLogic issue in JIRA.
>
>FYI, I've just noticed that I might have misinterpreted Victor's problem last night: He doesn't use Spring transactions with REQUIRES_NEW, but rather an outer Spring transaction plus an inner EJB CMT transaction with REQUIRES_NEW. Spring's JtaTransactionManager never touches the JTA TransactionManager is such a scenario, so it can't be caused by the suspend/resume interaction there.
>
>I rather suspect that the problem is Spring's transaction synchronization, which gets activated for the outer Spring transaction, but doesn't get notified of the transaction suspension caused by the inner EJB CMT transaction. Therefore, Spring's Hibernate support within the inner transaction will still synchronize with the outer Spring transaction, flushing the Hibernate Session at completion of the *outer* rather than the inner transaction.
>
>The solution I've suggested is to turn off Spring's transaction synchronization in that case. It should always be turned off when using transaction suspension driven by EJB CMT. See my JIRA comments:
>
>http://opensource.atlassian.com/projects/spring/browse/SPR-295
>
>As I've noted there, it would still be interesting whether Spring-driven JTA transaction suspension works with WebSphere: i.e., a Spring transaction demarcation with REQUIRES_NEW in case of an existing transaction. We might still face problems there, of course, but it seems to me that Victor's issue is not an indication for those.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von Thomas Risberg
>Gesendet: Di 31.08.2004 06:33
>An: spr...@li...
>Betreff: Re: [Springframework-developer] JTA transaction suspension on WebSphere
>
>
>
>This is not an issue for transactions declared with REQUIRED, SUPPORTS,
>MANDATORY or NEVER.  For these transactions there is no need to mess
>with the JTA TransactionManager to suspend the current transaction.
>UserTransaction is sufficient for these and this should be portable
>between containers.
>
>The only trouble is with REQUIRES_NEW and NOT_SUPPORTED.  Here we have
>to bend the rules and use the JTA TransactionManager API if it is
>available.  This is where things break down since the appservers don't
>seem to cooperate.  Even WebLogic 8.1 did not work until we used a
>WebLogic specific API call (forceResume).
>
>Thomas
>
>
>Colin Sampaleanu wrote:
>
>  
>
>>Eugene Kuleshov wrote:
>>
>>    
>>
>>>Colin Sampaleanu wrote:
>>>
>>>      
>>>
>>>>'Eu' on his blog 3-4 days ago commented based on my own blog entry,
>>>>and a forum message:
>>>> http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from
>>>>that section / C.2.4 /of the EJB spec says that the container, for
>>>>EJBs, must implement the UserTransaction interface (and JTA 1.0.1)
>>>>extension, but doesn't have to implement the other interfaces
>>>>defined in the JTA specification. Fine, I've actually seen that
>>>>before, coincidentally, when I was tracking something down a while
>>>>ago, but I think a container is fundamentally broken if it _does_
>>>>expose the JTA TransactionManager interface, and it doesn't behave
>>>>as per the spec. The spec for an API is the spec for the API. If you
>>>>expose the interface at all, then you need to expose it correctly...
>>>>That's essentially how I read that clause, and how I see things. In
>>>>any case, I hope the situation is going to improve, certainly WLS 8
>>>>works where WLS 7 doesn't, with out WL specific adapter...
>>>>        
>>>>
>>>
>>>  Perhaps I wasn't clear enough. My point is that it is a bad idea to
>>>mix usage of JTA interface with declarative container managed
>>>transacttions for EJBs. In other words it is probably to use Spring
>>>JTA helpers/wrappers in web layer which is not using EJB's.
>>>
>>>  Anyway it would be good have some more advanced tests to ensure
>>>that JTA actually work in WLS8 (and other containers) in case of
>>>failure/rollback with multiple XA resources involved into transaction
>>>(especially resources from different vendors, such as Oracle, Sybase,
>>>MQSeries).
>>>      
>>>
>>I fully agree about the tests. This is part of the reason I created
>>the ejbtest integration sample. Hopefully we will keep adding to it.
>>
>>As for the clause in question, it says:
>>
>>"The EJB container must include the JTA 1.0.1 extension, and it must
>>provide the javax.transaction.UserTransaction interface to  enterprise
>>beans with bean-managed transaction demarcation through the
>>javax.ejb.EJBContext interface, and also in JNDI under the name
>>java:comp/UserTransaction, in the cases required by the EJB
>>specification.
>>The other JTA interfaces are low-level transaction manager and
>>resource manager integration interfaces, and are not intended for
>>direct use by enterprise beans.
>>
>>This is unfortunately not worded very well in my opinion, in terms of
>>being very clear about CMT. Consider that this is the section of the
>>spec called 'The Container Provider's Responsibility'. It is about the
>>minimum set of services which the container must provide to the EJB. I
>>do not equate anything in the paragraphs above as saying (with any
>>adequate level of clarity) that if the container chooses to expose
>>other APIs the EJB _is not_ allowed to use them. I read the last
>>sentence as a justification as to _why_ the container doesn't have to
>>provide the other JTA interfaces. The spec is actually very specific
>>about what EJBs may and may not do, consider threading for example.
>>Again, my opinion is that if the container does choose to expose an
>>API like JTA's TransactionManager, then it has to behave correctly, as
>>an API is an API.
>>
>>Ultimately, only the spec writers know what they really intended, and
>>I agree that people wanting to move an app from container to
>>container, and from app server version to version, are not going to
>>get as predictable results in a CMT+Spring Transaction setup as they
>>would in a CMT alone, or Spring Tx alone setup. That said, it can
>>still be a viable and useful combination. Over a period of some
>>months, I migrated an app on JBoss from CMT EJB to no EJB with Spring
>>Tx wrapping service beans, and the CMT+Spring Tx combo provided a
>>valuable middle ground in the migration, in the perdio when there were
>>still some EJBs, but a lot had already moved over.
>>
>>Regards,
>>Colin
>>    
>>

Re: [Springframework-developer] JTA transaction suspension on WebSphere

[Colin S. <col...@ex...>]

We need to make the distinction in our docs between using Spring 
transactions, and actually turning on synchronization to the Spring tx 
manager. I don't think most people realize the latter is possible, or 
the consequences...

jürgen höller [werk3AT] wrote:

>An update: The issue was indeed caused by Spring's transaction synchronization in combination with EJB CMT transaction suspension. Once you turn off Spring's transaction synchronization, which causes our Hibernate support to fall back to direct JTA synchronization, everything works nicely. I've also refined our Hibernate LOB types to be able to work with direct JTA synchronization too, so that our full Hibernate support works in such a scenario without hassle.
> 
>Furthermore, Victor was so kind to test a variety of combinations with Spring-driven JTA transaction suspension on WebSphere, among those with an outer transaction that has been marked rollback-only (which doesn't work out-of-the-box on WebLogic). Fortunately, everything worked nicely!
> 
>Thus, it's now quite safe to assume that WebSphere's JTA TransactionManager is fully compatible with Spring, at least on WebSphere 4. It would be good to get some tests on WebSphere 5 - any volunteers? This means, to the best of our current knowledge, that we only need special handling (WebLogicJtaTransactionManager) on WebLogic, and that the only container where suspend/resume doesn't work in all cases is WebLogic 7.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von jürgen höller [werk3AT]
>Gesendet: Di 31.08.2004 10:58
>An: spr...@li...
>Betreff: Re: [Springframework-developer] JTA transaction suspension on WebSphere
>
>
>
>Indeed, Thomas: I've pointed out exactly the same to Eugene on that WebLogic issue in JIRA.
>
>FYI, I've just noticed that I might have misinterpreted Victor's problem last night: He doesn't use Spring transactions with REQUIRES_NEW, but rather an outer Spring transaction plus an inner EJB CMT transaction with REQUIRES_NEW. Spring's JtaTransactionManager never touches the JTA TransactionManager is such a scenario, so it can't be caused by the suspend/resume interaction there.
>
>I rather suspect that the problem is Spring's transaction synchronization, which gets activated for the outer Spring transaction, but doesn't get notified of the transaction suspension caused by the inner EJB CMT transaction. Therefore, Spring's Hibernate support within the inner transaction will still synchronize with the outer Spring transaction, flushing the Hibernate Session at completion of the *outer* rather than the inner transaction.
>
>The solution I've suggested is to turn off Spring's transaction synchronization in that case. It should always be turned off when using transaction suspension driven by EJB CMT. See my JIRA comments:
>
>http://opensource.atlassian.com/projects/spring/browse/SPR-295
>
>As I've noted there, it would still be interesting whether Spring-driven JTA transaction suspension works with WebSphere: i.e., a Spring transaction demarcation with REQUIRES_NEW in case of an existing transaction. We might still face problems there, of course, but it seems to me that Victor's issue is not an indication for those.
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag von Thomas Risberg
>Gesendet: Di 31.08.2004 06:33
>An: spr...@li...
>Betreff: Re: [Springframework-developer] JTA transaction suspension on WebSphere
>
>
>
>This is not an issue for transactions declared with REQUIRED, SUPPORTS,
>MANDATORY or NEVER.  For these transactions there is no need to mess
>with the JTA TransactionManager to suspend the current transaction.
>UserTransaction is sufficient for these and this should be portable
>between containers.
>
>The only trouble is with REQUIRES_NEW and NOT_SUPPORTED.  Here we have
>to bend the rules and use the JTA TransactionManager API if it is
>available.  This is where things break down since the appservers don't
>seem to cooperate.  Even WebLogic 8.1 did not work until we used a
>WebLogic specific API call (forceResume).
>
>Thomas
>
>
>Colin Sampaleanu wrote:
>
>  
>
>>Eugene Kuleshov wrote:
>>
>>    
>>
>>>Colin Sampaleanu wrote:
>>>
>>>      
>>>
>>>>'Eu' on his blog 3-4 days ago commented based on my own blog entry,
>>>>and a forum message:
>>>> http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from
>>>>that section / C.2.4 /of the EJB spec says that the container, for
>>>>EJBs, must implement the UserTransaction interface (and JTA 1.0.1)
>>>>extension, but doesn't have to implement the other interfaces
>>>>defined in the JTA specification. Fine, I've actually seen that
>>>>before, coincidentally, when I was tracking something down a while
>>>>ago, but I think a container is fundamentally broken if it _does_
>>>>expose the JTA TransactionManager interface, and it doesn't behave
>>>>as per the spec. The spec for an API is the spec for the API. If you
>>>>expose the interface at all, then you need to expose it correctly...
>>>>That's essentially how I read that clause, and how I see things. In
>>>>any case, I hope the situation is going to improve, certainly WLS 8
>>>>works where WLS 7 doesn't, with out WL specific adapter...
>>>>        
>>>>
>>>
>>>  Perhaps I wasn't clear enough. My point is that it is a bad idea to
>>>mix usage of JTA interface with declarative container managed
>>>transacttions for EJBs. In other words it is probably to use Spring
>>>JTA helpers/wrappers in web layer which is not using EJB's.
>>>
>>>  Anyway it would be good have some more advanced tests to ensure
>>>that JTA actually work in WLS8 (and other containers) in case of
>>>failure/rollback with multiple XA resources involved into transaction
>>>(especially resources from different vendors, such as Oracle, Sybase,
>>>MQSeries).
>>>      
>>>
>>I fully agree about the tests. This is part of the reason I created
>>the ejbtest integration sample. Hopefully we will keep adding to it.
>>
>>As for the clause in question, it says:
>>
>>"The EJB container must include the JTA 1.0.1 extension, and it must
>>provide the javax.transaction.UserTransaction interface to  enterprise
>>beans with bean-managed transaction demarcation through the
>>javax.ejb.EJBContext interface, and also in JNDI under the name
>>java:comp/UserTransaction, in the cases required by the EJB
>>specification.
>>The other JTA interfaces are low-level transaction manager and
>>resource manager integration interfaces, and are not intended for
>>direct use by enterprise beans.
>>
>>This is unfortunately not worded very well in my opinion, in terms of
>>being very clear about CMT. Consider that this is the section of the
>>spec called 'The Container Provider's Responsibility'. It is about the
>>minimum set of services which the container must provide to the EJB. I
>>do not equate anything in the paragraphs above as saying (with any
>>adequate level of clarity) that if the container chooses to expose
>>other APIs the EJB _is not_ allowed to use them. I read the last
>>sentence as a justification as to _why_ the container doesn't have to
>>provide the other JTA interfaces. The spec is actually very specific
>>about what EJBs may and may not do, consider threading for example.
>>Again, my opinion is that if the container does choose to expose an
>>API like JTA's TransactionManager, then it has to behave correctly, as
>>an API is an API.
>>
>>Ultimately, only the spec writers know what they really intended, and
>>I agree that people wanting to move an app from container to
>>container, and from app server version to version, are not going to
>>get as predictable results in a CMT+Spring Transaction setup as they
>>would in a CMT alone, or Spring Tx alone setup. That said, it can
>>still be a viable and useful combination. Over a period of some
>>months, I migrated an app on JBoss from CMT EJB to no EJB with Spring
>>Tx wrapping service beans, and the CMT+Spring Tx combo provided a
>>valuable middle ground in the migration, in the perdio when there were
>>still some EJBs, but a lot had already moved over.
>>
>>Regards,
>>Colin
>>    
>>

Re: [Springframework-developer] flush() method on HibernateTemplate

[Colin S. <col...@ex...>]

FLUSH_EAGER is not at all the same, in my opinion. When doing mixed 
Hibernate based code (with JDBC or EJBs) I on a number of occasions had 
to issue flushes to ensure something was safely available for the other 
code, but it was certainly nothing I wanted even most of the time 
(default FLUSH_EAGER)... And your typical DAO based on something like 
HibernateDaoSupport doesn't usually have the concept of working with 
multiple templates.

I was originally kind of against the idea, especially given the fact 
that in non Session bound to thread mode the operation would be 
completely redundant. But at the end of the day, the template is used by 
DAOs, DAOs are very aware of Hibernate specifics, and I think there's 
nothing fundamentally that wrong with allowing an explicit flush to be 
done in an easy fashion. I don't agree this operation is really related 
to transaction state either. Whether that data is in the Session cache 
or has gone out to the db, the transaction can generally still commit or 
rollback with the same effect. And Hibernate itself will on its own 
criteria also decide to flush the cache sometimes, such as when you do a 
query.  In the end, I think it's somewhat contrived if some app has to 
do a half dozen HibernateCallback cases where the only only operation 
inside them is a flush() call.


jürgen höller [werk3AT] wrote:

>Well, that's what HibernateTemplate's FLUSH_EAGER mode is meant for: To automatically flush right after each operation, even if a prebound Session is used. I would generally recommend to use such a preconfigured HibernateTemplate instance here, no matter if a shared one like in a HibernateDaoSupport or a newly instantiated one for a given SessionFactory.
> 
>I'm not keen on a flush operation on HibernateTemplate itself: That's not really a data access operation like the other methods there, but rather a method that just modifies the state of the transaction. If someone doesn't like the approach with a preconfigured HibernateTemplate, there's still the option of a custom HibernateCallback, even if just for a save and a flush.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Mi 01.09.2004 17:34
>An: spr...@li...
>Betreff: [Springframework-developer] flush() method on HibernateTemplate
>
>
>
>Juergen,
>
>We had a request on the forums (and I've seen this before) to add
>flush() as a method on HibernateTemplate. Of course, this would be
>completely useless (or superfluous) in the case there is no existing
>thread bound session (or at least an existing outer transaction to bind
>the new session to and keep it there afterwards). But most people do use
>HibernateTemplate in their DAOs with the expectation that the Session is
>already around or will be created and stay around, and it's probably
>reasonable to allow them to do a flush without having to use
>HibernateCallback, since they could have just done a one-off operation
>like save() and then want to ensure that changes go out, for example
>when combining with JDBC based operations in a DAO.
>
>What do you think?
>  
>

[Springframework-developer] =?GB2312?Q?=BF=EC=C0=B4=BF=B4=BF=B4=CE=D2=B5=C4=CD=B5=C5=C4=D7=F7=C6=B7?=

[playearth79 <pla...@to...>]

=C5=F3=D3=D1:
     =C4=E3=BA=C3!
   =

=CE=D2=CA=C7=C4=B3=CE=E5=D0=C7=BC=B6=BE=C6=B5=EA=B5=C4=BE=AD=C0=ED,=CD=AC=CA=B1=CE=D2=D2=B2=CA=C7=D2=BB=C3=FB=D7=A8=C5=C4=C9=E7=BB=E1=B3=F3=B6=F1=CF=D6=CF=F3=B5=C4=CD=B5=C5=C4=B0=AE=BA=C3=D5=
=DF,=BD=FC=C4=EA=C0=B4

=CE=D2=D4=DA=BE=C6=B5=EA=D2=BB=D0=A9=B8=DF=B5=B5=BF=CD=B7=BF=CD=B5=CD=B5=D7=B0=C9=CF=C9=E3=CF=F1=CD=B7,=CD=B5=C5=C4=C1=CB=C1=BD=B0=D9=B6=E0=B2=BF=D7=F7=C6=B7,=C0=EF=C3=E6=BC=C8=D3=D0=B7=F2=C6=
=DE=D0=C2=BB=E9=D6=AE=D2=B9=B5=C4

=B7=F2=C6=DE=C9=FA=BB=EE=C6=AC=B6=CE;=D2=B2=D3=D0=D1=DD=D2=D5=C8=A6=C4=DA=D2=BB=D0=A9=D1=DD=D4=B1=CE=AA=CC=D6=BA=C3=C3=FB=B5=BC=D1=DD=B7=A2=C9=FA=B5=C4=D0=D4=BD=BB=D2=D7=CA=B5=C2=BC;=C9=F5=D6=
=C1=BB=B9=D3=D0=D2=BB=D0=A9=B8=BB

=BA=C0=BB=A8=B8=DF=BC=DB=B9=BA=C2=F2=D6=D0=D1=A7=C5=AE=C9=FA=C3=C7=B3=F5=D2=B9=C8=A8,=B8=FC=CE=AA=BF=C9=B3=DC=B5=C4=CA=C7=BE=D3=C8=BB=BB=B9=CA=C7=D4=DA=B0=D7=CC=EC=BA=CD=C4=EA=BD=F6=CA=AE=CE=E5=
=A1=A2=C1=F9=CB=EA=B7=A2=D3=FD

=B2=BB=CC=AB=B3=C9=CA=EC=B5=C4=D6=D0=D1=A7=D0=A1=C5=AE=C9=FA=B7=A2=C9=FA=D0=D4=B9=D8=CF=B5,=D2=F2=B4=CB=C6=E4=B3=F3=B6=F1=D0=D0=BE=B6=C5=C4=B5=C3=B8=FC=C7=E5=B3=FE=B2=BB=B9=FD=C1=CB,=D5=E2=D0=
=A9=B8=BB=BA=C0=C3=C7=CD=CB=B7=BF

=BA=F3=B1=BE=C8=CB=BB=B9=D4=DA=C6=E4=B7=BF=BC=E4=C5=C4=B5=BD=C1=CB=B4=B2=B5=A5=C9=CF=C6=E4=D3=EB=D6=D0=D1=A7=C5=AE=C9=FA=B7=A2=C9=FA=D0=D4=B9=D8=CF=B5=C1=F4=CF=C2=B5=C4=CF=CA=BA=EC=B5=C4=D1=AA=BC=
=A3.=CE=AA=C1=CB=BD=D2=C2=B6

=C9=E7=BB=E1=B5=C4=D5=E2=D0=A9=B3=F3=B6=F1=CF=D6=CF=F3,=C8=C3=D5=E2=D0=A9=C8=CB=BD=D3=CA=DC=C9=E7=BB=E1=B5=C4=C7=B4=D4=F0,=B1=BE=C8=CB=CC=D8=BF=AA=B0=EC"=D6=D0=B9=FA=B3=F3=B6=F1=CF=D6=CF=F3=
=CD=B5=B2=AE=CD=F8",=BD=AB

=B1=BE=C8=CB=CD=B5=C5=C4=B5=BD=B5=C4=D5=E2=D0=A9=C9=E7=BB=E1=B3=F3=B6=F1=B7=BD=C3=E6=B5=C4=D7=F7=C6=B7=B9=AB=BF=AA,=CF=A3=CD=FB=C4=DC=B5=C3=B5=BD=CD=F8=D3=D1=C3=C7=B5=C4=D6=A7=B3=D6,=C8=E7=B9=
=FB=C4=E3=D2=B2=D3=D0=B9=D8=D3=DA

=D5=E2=B7=BD=C3=E6=B5=C4=D7=F7=C6=B7,=D2=B2=BF=C9=D2=D4=D4=DA=B1=BE=C8=CB=B5=C4=CD=F8=D5=BE=C9=CF=B7=A2=B2=BC.
   =
 "=D6=D0=B9=FA=B3=F3=B6=F1=CF=D6=CF=F3=CD=B5=C5=C4=CD=F8"=CD=F8=D6=B7:http://chinaweb.a184.zgsj.com/index.htm=
,=BB=B6=D3=AD=B7=C3

=CE=CA,=CF=A3=CD=FB=C4=DC=B5=C3=B5=BD=B4=F3=BC=D2=B5=C4=D6=A7=B3=D6,=B1=BE=CD=F8=D5=BE=CF=B5=B9=AB=D2=E6=D0=D4=CD=F8=D5=BE,=CE=DE=C8=CE=BA=CE=B9=E3=B8=E6,=CD=B5=C5=C4=D3=B0=C6=AC=C8=AB=B2=
=BF=B2=C9=D3=C3asx=B8=F1

=CA=BD=D1=B9=CB=F5,=C8=E7=B9=FB=C4=FA=B5=C4=CF=B5=CD=B3=C3=BB=D3=D0=B0=B2=D7=B0=BD=E2=C2=EB=C6=F7,=BF=C9=D2=D4=D4=DA=B1=BE=D5=BE=D4=DA=CF=DF=B0=B2=D7=B0=BB=F2=CF=C2=D4=D8=B0=B2=D7=B0=BC=B4=BF=
=C9=B9=DB=C9=CD=B1=BE=C8=CB=B5=C4

=D7=F7=C6=B7.


                                                  =
 =D6=D0=B9=FA=B3=F3=B6=F1=CF=D6=CF=F3=CD=B5=B2=AE=CD=F8

[Springframework-developer] spring build.92 Build Successful

[<al...@jt...>]

<html><head>
<style>
.white { color:#FFFFFF }.index { background-color:#FFFFFF }.index-passed { =
color:#004400 }.index-failed { color:#FF0000; font-weight:bold }.index-head=
er { font-weight:bold }.link { font-family:arial,helvetica,sans-serif; font=
-size:10pt; color:#FFFFFF; text-decoration:none; }.tab-table { margin: 0em =
0em 0.5em 0em; }.tabs { font-family:arial,helvetica,sans-serif; font-size:8=
pt; color:#000000; font-weight:bold; padding: 0em 2em; background-color:#EE=
EEEE; }.tabs-link { color:#000000; text-decoration:none; }.tabs-link:visite=
d { color:#000000; text-decoration:none; }.tabs-selected { font-family:aria=
l,helvetica,sans-serif; font-size:8pt; color:#000000; font-weight:bold; pad=
ding: 0em 2em; }.tabs-selected { border: inset; }.header-title { font-famil=
y:arial,helvetica,sans-serif; font-size:12pt; color:#000000; font-weight:bo=
ld; }.header-label { font-weight:bold; }.header-data { font-family:arial,he=
lvetica,sans-serif; font-size:10pt; color:#000000; }.modifications-data { f=
ont-family:arial,helvetica,sans-serif; font-size:8pt; color:#000000; }.modi=
fications-sectionheader { background-color:#000066; font-family:arial,helve=
tica,sans-serif; font-size:10pt; color:#FFFFFF; }.modifications-oddrow { ba=
ckground-color:#CCCCCC }.modifications-evenrow { background-color:#FFFFCC }=
.changelists-oddrow { background-color:#CCCCCC }.changelists-evenrow { back=
ground-color:#FFFFCC }.changelists-file-spacer { background-color:#FFFFFF }=
.changelists-file-evenrow { background-color:#EEEEEE }.changelists-file-odd=
row { background-color:#FFFFEE }.changelists-file-header { background-color=
:#666666; font-family:arial,helvetica,sans-serif; font-size:8pt; color:#FFF=
FFF; }.compile-data { font-family:arial,helvetica,sans-serif; font-size:8pt=
; color:#000000; }.compile-error-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#FF0000; }.compile-warn-data { font-family:arial,=
helvetica,sans-serif; font-size:8pt; color:#CC9900; }.compile-sectionheader=
 { background-color:#000066; font-family:arial,helvetica,sans-serif; font-s=
ize:10pt; color:#FFFFFF; }.distributables-data { font-family:arial,helvetic=
a,sans-serif; font-size:8pt; color:#000000; }.distributables-sectionheader =
{ background-color:#000066; font-family:arial,helvetica,sans-serif; font-si=
ze:10pt; color:#FFFFFF; }.distributables-oddrow { background-color:#CCCCCC =
}.unittests-sectionheader { background-color:#000066; font-family:arial,hel=
vetica,sans-serif; font-size:10pt; color:#FFFFFF; }.unittests-oddrow { back=
ground-color:#CCCCCC }.unittests-data { font-family:arial,helvetica,sans-se=
rif; font-size:8pt; color:#000000; }.unittests-error { font-family:arial,he=
lvetica,sans-serif; font-size:8pt; color:#FF0000; }.checkstyle-oddrow { bac=
kground-color:#CCCCCC }.checkstyle-data { font-family:arial,helvetica,sans-=
serif; font-size:8pt; color:#000000; }.checkstyle-sectionheader { backgroun=
d-color:#000066; font-family:arial,helvetica,sans-serif; font-size:10pt; co=
lor:#FFFFFF; }
</style>
</head><body>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"header-title">BUILD COMPLETE&nbsp;-&nbsp;     =
               build.92</td></tr><tr><td class=3D"header-data"><span class=
=3D"header-label">Date of build:&nbsp;</span>09/02/2004 00:16:34</td></tr><=
tr><td class=3D"header-data"><span class=3D"header-label">Time to build:&nb=
sp;</span>13 minutes 24 seconds</td></tr><tr><td class=3D"header-data"><spa=
n class=3D"header-label">Last changed:&nbsp;</span>09/01/2004 12:24:55</td>=
</tr><tr><td class=3D"header-data"><span class=3D"header-label">Last log en=
try:&nbsp;</span>polishing</td></tr></table><p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"/><p>
<p>
<table xmlns=3D"http://www.w3.org/TR/html4/strict.dtd" width=3D"98%" border=
=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"center"><tr><td class=
=3D"compile-sectionheader">                        &nbsp;Errors/Warnings: (=
6)                    </td></tr><tr><td><pre class=3D"compile-error-data">N=
ote: Some input files use or override a deprecated API.<br class=3D"none"/>=
Note: Recompile with -deprecation for details.Note: /jteam/build/checkout/s=
pring/spring/mock/org/springframework/mock/web/MockHttpSession.java uses or=
 overrides a deprecated API.<br class=3D"none"/>Note: Recompile with -depre=
cation for details.<br class=3D"none"/>Note: Some input files use or overri=
de a deprecated API.<br class=3D"none"/>Note: Recompile with -deprecation f=
or details.<br class=3D"none"/></pre></td></tr></table><p>
<p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"unittests-sectionheader">       =
            &nbsp;Unit Tests: (1470)                </td></tr><tr><td><tabl=
e width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=3D"c=
enter"><tr><td class=3D"unittests-data">                failure            =
</td><td width=3D"40%" class=3D"unittests-data">testHomePage</td><td width=
=3D"40%" class=3D"unittests-data">org.springframework.apptests.buildtest.Al=
lTests</td></tr></table></td></tr><tr></tr><tr><td colspan=3D"2">&nbsp;</td=
></tr><tr><td colspan=3D"4" class=3D"unittests-sectionheader">             =
       &nbsp;Unit Test Error Details:&nbsp;(1)                </td></tr><tr=
><td class=3D"unittests-data" colspan=3D"2">                Test:&nbsp;test=
HomePage</td></tr><tr><td class=3D"unittests-data" colspan=3D"2">          =
      Class:&nbsp;org.springframework.apptests.buildtest.AllTests</td></tr>=
<tr><td class=3D"unittests-data" colspan=3D"2">                Type: junit.=
framework.AssertionFailedError</td></tr><tr><td class=3D"unittests-data" co=
lspan=3D"2">                Message: Exception while testing URL http://loc=
alhost:13084/buildtest:java.io.IOException</td></tr><tr><td class=3D"unitte=
sts-error" colspan=3D"2"><pre>junit.framework.AssertionFailedError: Excepti=
on while testing URL http://localhost:13084/buildtest:java.io.IOException<b=
r>=09at org.springframework.apptests.buildtest.AllTests.testHomePage(Unknow=
n Source)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meth=
od)<br>=09at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess=
orImpl.java:39)<br>=09at sun.reflect.DelegatingMethodAccessorImpl.invoke(De=
legatingMethodAccessorImpl.java:25)<br></pre></td></tr><tr><td colspan=3D"2=
">&nbsp;</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td colspan=3D"4" class=3D"modifications-sectionheader">   =
                 &nbsp;Modifications since last build:&nbsp;               =
     (24)                </td></tr><tr class=3D"modifications-evenrow"><td =
class=3D"modifications-data">modified</td><td class=3D"modifications-data">=
jhoeller</td><td class=3D"modifications-data">test/org/springframework/jdbc=
/core/support/SqlLobValueTestSuite.java</td><td class=3D"modifications-data=
">polishing</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifi=
cations-data">modified</td><td class=3D"modifications-data">jhoeller</td><t=
d class=3D"modifications-data">test/org/springframework/orm/hibernate/suppo=
rt/LobTypeTests.java</td><td class=3D"modifications-data">added BlobSeriali=
zableType</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modific=
ations-data">added</td><td class=3D"modifications-data">jhoeller</td><td cl=
ass=3D"modifications-data">src/org/springframework/orm/hibernate/support/Bl=
obSerializableType.java</td><td class=3D"modifications-data">added BlobSeri=
alizableType</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modif=
ications-data">modified</td><td class=3D"modifications-data">jhoeller</td><=
td class=3D"modifications-data">src/org/springframework/orm/hibernate/suppo=
rt/AbstractLobType.java</td><td class=3D"modifications-data">allow template=
 methods to throw IOException</td></tr><tr class=3D"modifications-evenrow">=
<td class=3D"modifications-data">modified</td><td class=3D"modifications-da=
ta">jhoeller</td><td class=3D"modifications-data">src/org/springframework/j=
dbc/support/lob/DefaultLobHandler.java</td><td class=3D"modifications-data"=
>polishing</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modific=
ations-data">modified</td><td class=3D"modifications-data">jhoeller</td><td=
 class=3D"modifications-data">src/org/springframework/jdbc/support/lob/LobC=
reator.java</td><td class=3D"modifications-data">polishing</td></tr><tr cla=
ss=3D"modifications-evenrow"><td class=3D"modifications-data">modified</td>=
<td class=3D"modifications-data">jhoeller</td><td class=3D"modifications-da=
ta">src/org/springframework/jdbc/support/lob/OracleLobHandler.java</td><td =
class=3D"modifications-data">delegate to FileCopyUtils as far as possible</=
td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications-data"=
>modified</td><td class=3D"modifications-data">jhoeller</td><td class=3D"mo=
difications-data">/changelog.txt</td><td class=3D"modifications-data">"stub=
" rather than "rmiProxy"</td></tr><tr class=3D"modifications-evenrow"><td c=
lass=3D"modifications-data">modified</td><td class=3D"modifications-data">j=
hoeller</td><td class=3D"modifications-data">samples/petclinic/src/org/spri=
ngframework/samples/petclinic/web/AddOwnerForm.java</td><td class=3D"modifi=
cations-data">consistent use of "int" rather than "long"</td></tr><tr class=
=3D"modifications-oddrow"><td class=3D"modifications-data">modified</td><td=
 class=3D"modifications-data">jhoeller</td><td class=3D"modifications-data"=
>samples/petclinic/src/org/springframework/samples/petclinic/web/AddVisitFo=
rm.java</td><td class=3D"modifications-data">consistent use of "int" rather=
 than "long"</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modi=
fications-data">modified</td><td class=3D"modifications-data">jhoeller</td>=
<td class=3D"modifications-data">samples/petclinic/src/org/springframework/=
samples/petclinic/web/EditOwnerForm.java</td><td class=3D"modifications-dat=
a">consistent use of "int" rather than "long"</td></tr><tr class=3D"modific=
ations-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"m=
odifications-data">jhoeller</td><td class=3D"modifications-data">samples/pe=
tclinic/src/org/springframework/samples/petclinic/web/FindOwnersForm.java</=
td><td class=3D"modifications-data">consistent use of "int" rather than "lo=
ng"</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifications=
-data">modified</td><td class=3D"modifications-data">jhoeller</td><td class=
=3D"modifications-data">samples/petclinic/src/org/springframework/samples/p=
etclinic/util/EntityUtils.java</td><td class=3D"modifications-data">consist=
ent use of "int" rather than "long"</td></tr><tr class=3D"modifications-odd=
row"><td class=3D"modifications-data">modified</td><td class=3D"modificatio=
ns-data">jhoeller</td><td class=3D"modifications-data">samples/jpetstore/sr=
c/org/springframework/samples/jpetstore/web/spring/AccountFormController.ja=
va</td><td class=3D"modifications-data">polishing</td></tr><tr class=3D"mod=
ifications-evenrow"><td class=3D"modifications-data">modified</td><td class=
=3D"modifications-data">jhoeller</td><td class=3D"modifications-data">sampl=
es/petclinic/src/org/springframework/samples/petclinic/jdbc/AbstractJdbcCli=
nic.java</td><td class=3D"modifications-data">consistent use of "int" rathe=
r than "long"</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modi=
fications-data">modified</td><td class=3D"modifications-data">jhoeller</td>=
<td class=3D"modifications-data">samples/petclinic/src/org/springframework/=
samples/petclinic/web/AddPetForm.java</td><td class=3D"modifications-data">=
override onBind rather than onBindAndValidate</td></tr><tr class=3D"modific=
ations-evenrow"><td class=3D"modifications-data">modified</td><td class=3D"=
modifications-data">jhoeller</td><td class=3D"modifications-data">samples/p=
etclinic/src/org/springframework/samples/petclinic/web/EditPetForm.java</td=
><td class=3D"modifications-data">override onBind rather than onBindAndVali=
date</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifications=
-data">deleted</td><td class=3D"modifications-data">jhoeller</td><td class=
=3D"modifications-data">test/org/springframework/remoting/HttpInvokerTestSu=
ite.java</td><td class=3D"modifications-data">refactored test suite into su=
bpackages</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modific=
ations-data">deleted</td><td class=3D"modifications-data">jhoeller</td><td =
class=3D"modifications-data">test/org/springframework/remoting/JaxRpcTestSu=
ite.java</td><td class=3D"modifications-data">refactored test suite into su=
bpackages</td></tr><tr class=3D"modifications-oddrow"><td class=3D"modifica=
tions-data">deleted</td><td class=3D"modifications-data">jhoeller</td><td c=
lass=3D"modifications-data">test/org/springframework/remoting/RemotingTestS=
uite.java</td><td class=3D"modifications-data">refactored test suite into s=
ubpackages</td></tr><tr class=3D"modifications-evenrow"><td class=3D"modifi=
cations-data">modified</td><td class=3D"modifications-data">jhoeller</td><t=
d class=3D"modifications-data">src/org/springframework/remoting/rmi/JndiRmi=
ClientInterceptor.java</td><td class=3D"modifications-data">consistent use =
of the term "stub" rather than "rmiProxy"</td></tr><tr class=3D"modificatio=
ns-oddrow"><td class=3D"modifications-data">modified</td><td class=3D"modif=
ications-data">jhoeller</td><td class=3D"modifications-data">src/org/spring=
framework/remoting/rmi/RmiClientInterceptor.java</td><td class=3D"modificat=
ions-data">consistent use of the term "stub" rather than "rmiProxy"</td></t=
r><tr class=3D"modifications-evenrow"><td class=3D"modifications-data">modi=
fied</td><td class=3D"modifications-data">jhoeller</td><td class=3D"modific=
ations-data">src/org/springframework/remoting/rmi/RmiClientInterceptorUtils=
.java</td><td class=3D"modifications-data">consistent use of the term "stub=
" rather than "rmiProxy"</td></tr><tr class=3D"modifications-oddrow"><td cl=
ass=3D"modifications-data">modified</td><td class=3D"modifications-data">jh=
oeller</td><td class=3D"modifications-data">src/org/springframework/remotin=
g/jaxrpc/JaxRpcPortClientInterceptor.java</td><td class=3D"modifications-da=
ta">redesigned "postProcessPortProxy(Remote)" method as "postProcessPortStu=
b(Stub)"</td></tr></table><p>
<table width=3D"98%" border=3D"0" cellspacing=3D"0" cellpadding=3D"2" align=
=3D"center"><tr><td class=3D"distributables-sectionheader">                =
        &nbsp;Deployments by this build:&nbsp;(8)                    </td><=
/tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/checko=
ut/spring/spring/dist/spring.jar</td></tr><tr class=3D"distributables-oddro=
w"><td class=3D"distributables-data">Building war: /jteam/build/checkout/sp=
ring/spring/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr><td c=
lass=3D"distributables-data">Building war: /jteam/build/checkout/spring/spr=
ing/autobuilds/apps/buildtest/dist/buildtest.war</td></tr><tr class=3D"dist=
ributables-oddrow"><td class=3D"distributables-data">Building war: /jteam/b=
uild/checkout/spring/spring/autobuilds/apps/buildtest/dist/buildtest.war</t=
d></tr><tr><td class=3D"distributables-data">Building jar: /jteam/build/che=
ckout/spring/spring/autobuilds/apps/jpetstore/war/WEB-INF/lib/jpetstore.jar=
</td></tr><tr class=3D"distributables-oddrow"><td class=3D"distributables-d=
ata">Building war: /jteam/build/checkout/spring/spring/autobuilds/apps/jpet=
store/dist/jpetstore.war</td></tr><tr><td class=3D"distributables-data">Bui=
lding jar: /jteam/build/checkout/spring/spring/autobuilds/apps/jpetstore/wa=
r/WEB-INF/lib/jpetstore.jar</td></tr><tr class=3D"distributables-oddrow"><t=
d class=3D"distributables-data">Building war: /jteam/build/checkout/spring/=
spring/autobuilds/apps/jpetstore/dist/jpetstore.war</td></tr></table>
</body></html>

Re: [Springframework-developer] JTA transaction suspension on WebSphere

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

A further update: I've just discovered that WebLogic even officially =
supports javax.transaction.TransactionManager as public API!
=20
http://e-docs.bea.com/wls/docs70/jta/jtaapi.html
=20
"Client-initiated transactions-the JTA transaction manager interface =
(javax.transaction.TransactionManager) is made available to clients and =
bean providers through JNDI. This allows clients and EJBs using =
bean-managed transactions to suspend and resume transactions."
=20
They only interpret the semantics of resume a bit differently, i.e. not =
automatically resuming a transaction that has been marked rollback-only. =
They explicitly offer their proprietary forceResume method for this. =
It's quite clearly a bug then that it doesn't work in WebLogic 7.0: We =
could even try to report that to BEA! It does work in WebLogic 8.1, =
though...
=20
So in principle, suspend/resume via the JTA TransactionManager *is* =
supported by WebLogic, just with special semantics. And if you need the =
forceResume semantics, you can use Spring's new =
WebLogicJtaTransactionManager. Essentially, the JTA spec should be =
clearer about the semantics of TransactionManager.resume here...

Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Mi 01.09.2004 22:01
An: spr...@li...
Betreff: Re: [Springframework-developer] JTA transaction suspension on =
WebSphere



An update: The issue was indeed caused by Spring's transaction =
synchronization in combination with EJB CMT transaction suspension. Once =
you turn off Spring's transaction synchronization, which causes our =
Hibernate support to fall back to direct JTA synchronization, everything =
works nicely. I've also refined our Hibernate LOB types to be able to =
work with direct JTA synchronization too, so that our full Hibernate =
support works in such a scenario without hassle.

Furthermore, Victor was so kind to test a variety of combinations with =
Spring-driven JTA transaction suspension on WebSphere, among those with =
an outer transaction that has been marked rollback-only (which doesn't =
work out-of-the-box on WebLogic). Fortunately, everything worked nicely!

Thus, it's now quite safe to assume that WebSphere's JTA =
TransactionManager is fully compatible with Spring, at least on =
WebSphere 4. It would be good to get some tests on WebSphere 5 - any =
volunteers? This means, to the best of our current knowledge, that we =
only need special handling (WebLogicJtaTransactionManager) on WebLogic, =
and that the only container where suspend/resume doesn't work in all =
cases is WebLogic 7.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Di 31.08.2004 10:58
An: spr...@li...
Betreff: Re: [Springframework-developer] JTA transaction suspension on =
WebSphere



Indeed, Thomas: I've pointed out exactly the same to Eugene on that =
WebLogic issue in JIRA.

FYI, I've just noticed that I might have misinterpreted Victor's problem =
last night: He doesn't use Spring transactions with REQUIRES_NEW, but =
rather an outer Spring transaction plus an inner EJB CMT transaction =
with REQUIRES_NEW. Spring's JtaTransactionManager never touches the JTA =
TransactionManager is such a scenario, so it can't be caused by the =
suspend/resume interaction there.

I rather suspect that the problem is Spring's transaction =
synchronization, which gets activated for the outer Spring transaction, =
but doesn't get notified of the transaction suspension caused by the =
inner EJB CMT transaction. Therefore, Spring's Hibernate support within =
the inner transaction will still synchronize with the outer Spring =
transaction, flushing the Hibernate Session at completion of the *outer* =
rather than the inner transaction.

The solution I've suggested is to turn off Spring's transaction =
synchronization in that case. It should always be turned off when using =
transaction suspension driven by EJB CMT. See my JIRA comments:

http://opensource.atlassian.com/projects/spring/browse/SPR-295

As I've noted there, it would still be interesting whether Spring-driven =
JTA transaction suspension works with WebSphere: i.e., a Spring =
transaction demarcation with REQUIRES_NEW in case of an existing =
transaction. We might still face problems there, of course, but it seems =
to me that Victor's issue is not an indication for those.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Thomas Risberg
Gesendet: Di 31.08.2004 06:33
An: spr...@li...
Betreff: Re: [Springframework-developer] JTA transaction suspension on =
WebSphere



This is not an issue for transactions declared with REQUIRED, SUPPORTS,
MANDATORY or NEVER.  For these transactions there is no need to mess
with the JTA TransactionManager to suspend the current transaction.
UserTransaction is sufficient for these and this should be portable
between containers.

The only trouble is with REQUIRES_NEW and NOT_SUPPORTED.  Here we have
to bend the rules and use the JTA TransactionManager API if it is
available.  This is where things break down since the appservers don't
seem to cooperate.  Even WebLogic 8.1 did not work until we used a
WebLogic specific API call (forceResume).

Thomas


Colin Sampaleanu wrote:

> Eugene Kuleshov wrote:
>
>> Colin Sampaleanu wrote:
>>
>>> 'Eu' on his blog 3-4 days ago commented based on my own blog entry,
>>> and a forum message:
>>>  =
http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from
>>> that section / C.2.4 /of the EJB spec says that the container, for
>>> EJBs, must implement the UserTransaction interface (and JTA 1.0.1)
>>> extension, but doesn't have to implement the other interfaces
>>> defined in the JTA specification. Fine, I've actually seen that
>>> before, coincidentally, when I was tracking something down a while
>>> ago, but I think a container is fundamentally broken if it _does_
>>> expose the JTA TransactionManager interface, and it doesn't behave
>>> as per the spec. The spec for an API is the spec for the API. If you
>>> expose the interface at all, then you need to expose it correctly...
>>> That's essentially how I read that clause, and how I see things. In
>>> any case, I hope the situation is going to improve, certainly WLS 8
>>> works where WLS 7 doesn't, with out WL specific adapter...
>>
>>
>>
>>   Perhaps I wasn't clear enough. My point is that it is a bad idea to
>> mix usage of JTA interface with declarative container managed
>> transacttions for EJBs. In other words it is probably to use Spring
>> JTA helpers/wrappers in web layer which is not using EJB's.
>>
>>   Anyway it would be good have some more advanced tests to ensure
>> that JTA actually work in WLS8 (and other containers) in case of
>> failure/rollback with multiple XA resources involved into transaction
>> (especially resources from different vendors, such as Oracle, Sybase,
>> MQSeries).
>
>
> I fully agree about the tests. This is part of the reason I created
> the ejbtest integration sample. Hopefully we will keep adding to it.
>
> As for the clause in question, it says:
>
> "The EJB container must include the JTA 1.0.1 extension, and it must
> provide the javax.transaction.UserTransaction interface to  enterprise
> beans with bean-managed transaction demarcation through the
> javax.ejb.EJBContext interface, and also in JNDI under the name
> java:comp/UserTransaction, in the cases required by the EJB
> specification.
> The other JTA interfaces are low-level transaction manager and
> resource manager integration interfaces, and are not intended for
> direct use by enterprise beans.
>
> This is unfortunately not worded very well in my opinion, in terms of
> being very clear about CMT. Consider that this is the section of the
> spec called 'The Container Provider's Responsibility'. It is about the
> minimum set of services which the container must provide to the EJB. I
> do not equate anything in the paragraphs above as saying (with any
> adequate level of clarity) that if the container chooses to expose
> other APIs the EJB _is not_ allowed to use them. I read the last
> sentence as a justification as to _why_ the container doesn't have to
> provide the other JTA interfaces. The spec is actually very specific
> about what EJBs may and may not do, consider threading for example.
> Again, my opinion is that if the container does choose to expose an
> API like JTA's TransactionManager, then it has to behave correctly, as
> an API is an API.
>
> Ultimately, only the spec writers know what they really intended, and
> I agree that people wanting to move an app from container to
> container, and from app server version to version, are not going to
> get as predictable results in a CMT+Spring Transaction setup as they
> would in a CMT alone, or Spring Tx alone setup. That said, it can
> still be a viable and useful combination. Over a period of some
> months, I migrated an app on JBoss from CMT EJB to no EJB with Spring
> Tx wrapping service beans, and the CMT+Spring Tx combo provided a
> valuable middle ground in the migration, in the perdio when there were
> still some EJBs, but a lot had already moved over.
>
> Regards,
> Colin
>
>
>
>
> -------------------------------------------------------
> 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
>
>
>



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




-------------------------------------------------------
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_idP47&alloc_id=10808&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer




-------------------------------------------------------
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_idP47&alloc_id=10808&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] StatementCreatorUtils

[Dmitriy K. <dko...@ru...>]

I don't see any problems with that. +1.

Dmitriy.

jürgen höller [werk3AT] wrote:

>Changing auto-conversion in the unknown type case to java.sql.Timestamp is fine with me.
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von tho...@tr...
>Gesendet: Mi 01.09.2004 23:23
>An: spr...@li...
>Betreff: Re: [Springframework-developer] StatementCreatorUtils
>
>
>
>I tested setObject with both a java.sql.Date and a java.sql.Timestamp and the
>databases I tested on (MSSQL Server, MySQL, Postgres, Oracle) all behaved well
>for both.  The advatage with the Timstamp is that you retain the time portion.
>If no one objects I'll change the auto conversion to use a Timestamp.
>
>Thomas
>
>
>Quoting "jürgen höller [werk3AT]" <jue...@we...>:
>
>  
>
>>Good point. However, the driver respectively database might behave =
>>differently, as the passed-in object implicitly leads to a corresponding =
>>SQL type (i.e. DATE or TIMESTAMP): Will the database complain if it =
>>receives a timestamp value for a date field? Will it complain the other =
>>way round?
>>=20
>>It's certainly recommendable to pass the SQL type in for such a value. =
>>The question is: What's the safest default for the type if we receive a =
>>plain java.util.Date? Which implicit SQL type will work with most =
>>databases in a predictable manner?
>>=20
>>Juergen
>>=20
>>
>>________________________________
>>
>>Von: spr...@li... im Auftrag =
>>von tho...@tr...
>>Gesendet: Di 31.08.2004 22:56
>>An: spr...@li...
>>Betreff: Re: [Springframework-developer] StatementCreatorUtils
>>
>>
>>
>>Wouldn't java.sql.Timestamp be a better choice for java.util.Date and
>>java.util.Calendar with unknow SQL type?  That way you would not lose =
>>the time
>>portion.
>>
>>Thomas
>>
>>
>>Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:
>>
>>    
>>
>>>I've adapted StatementCreatorUtils as follows:
>>>
>>>* StatementCreatorUtils uses specific PreparedStatement parameter =
>>>      
>>>
>>setter =3D
>>    
>>
>>>methods, as far as possible
>>>* added auto-conversion of java.util.Calendar to =3D
>>>java.sql.Date/Time/Timestamp, for SQL types DATE/TIME/TIMESTAMP
>>>* added auto-conversion of java.util.Date and java.util.Calendar to =
>>>      
>>>
>>=3D
>>    
>>
>>>java.sql.Date, in case of an unknown SQL type
>>>
>>>This was partly triggered by
>>>http://opensource.atlassian.com/projects/spring/browse/SPR-301
>>>
>>>Thomas and co, please give the new version a try. It should =
>>>      
>>>
>>essentially =3D
>>    
>>
>>>work the same as before, just do a few more auto-conversions.
>>>
>>>Juergen
>>>
>>>
>>>-------------------------------------------------------
>>>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
>>>
>>>      
>>>
>>
>>
>>
>>-------------------------------------------------------
>>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
>>
>>
>>
>>
>>-------------------------------------------------------
>>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=5047&alloc_id=10808&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>    
>>
>
>
>
>
>
>-------------------------------------------------------
>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=5047&alloc_id=10808&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
>-------------------------------------------------------
>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_idP47&alloc_id808&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

Re: [Springframework-developer] StatementCreatorUtils

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

Changing auto-conversion in the unknown type case to java.sql.Timestamp =
is fine with me.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von tho...@tr...
Gesendet: Mi 01.09.2004 23:23
An: spr...@li...
Betreff: Re: [Springframework-developer] StatementCreatorUtils



I tested setObject with both a java.sql.Date and a java.sql.Timestamp =
and the
databases I tested on (MSSQL Server, MySQL, Postgres, Oracle) all =
behaved well
for both.  The advatage with the Timstamp is that you retain the time =
portion.
If no one objects I'll change the auto conversion to use a Timestamp.

Thomas


Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:

> Good point. However, the driver respectively database might behave =3D
> differently, as the passed-in object implicitly leads to a =
corresponding =3D
> SQL type (i.e. DATE or TIMESTAMP): Will the database complain if it =
=3D
> receives a timestamp value for a date field? Will it complain the =
other =3D
> way round?
> =3D20
> It's certainly recommendable to pass the SQL type in for such a value. =
=3D
> The question is: What's the safest default for the type if we receive =
a =3D
> plain java.util.Date? Which implicit SQL type will work with most =3D
> databases in a predictable manner?
> =3D20
> Juergen
> =3D20
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
=3D
> von tho...@tr...
> Gesendet: Di 31.08.2004 22:56
> An: spr...@li...
> Betreff: Re: [Springframework-developer] StatementCreatorUtils
>
>
>
> Wouldn't java.sql.Timestamp be a better choice for java.util.Date and
> java.util.Calendar with unknow SQL type?  That way you would not lose =
=3D
> the time
> portion.
>
> Thomas
>
>
> Quoting "j=3DFCrgen h=3DF6ller [werk3AT]" =
<jue...@we...>:
>
> > I've adapted StatementCreatorUtils as follows:
> >
> > * StatementCreatorUtils uses specific PreparedStatement parameter =
=3D
> setter =3D3D
> > methods, as far as possible
> > * added auto-conversion of java.util.Calendar to =3D3D
> > java.sql.Date/Time/Timestamp, for SQL types DATE/TIME/TIMESTAMP
> > * added auto-conversion of java.util.Date and java.util.Calendar to =
=3D
> =3D3D
> > java.sql.Date, in case of an unknown SQL type
> >
> > This was partly triggered by
> > http://opensource.atlassian.com/projects/spring/browse/SPR-301
> >
> > Thomas and co, please give the new version a try. It should =3D
> essentially =3D3D
> > work the same as before, just do a few more auto-conversions.
> >
> > Juergen
> >
> >
> > -------------------------------------------------------
> > 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=3D3D5047&alloc_id=3D3D10808&op=3D3Dclick
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>
>
>
> -------------------------------------------------------
> 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=3D3D5047&alloc_id=3D3D10808&op=3D3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> 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
>





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

Re: [Springframework-developer] StatementCreatorUtils

[<tho...@tr...>]

I tested setObject with both a java.sql.Date and a java.sql.Timestamp and the
databases I tested on (MSSQL Server, MySQL, Postgres, Oracle) all behaved well
for both.  The advatage with the Timstamp is that you retain the time portion. 
If no one objects I'll change the auto conversion to use a Timestamp.

Thomas


Quoting "jürgen höller [werk3AT]" <jue...@we...>:

> Good point. However, the driver respectively database might behave =
> differently, as the passed-in object implicitly leads to a corresponding =
> SQL type (i.e. DATE or TIMESTAMP): Will the database complain if it =
> receives a timestamp value for a date field? Will it complain the other =
> way round?
> =20
> It's certainly recommendable to pass the SQL type in for such a value. =
> The question is: What's the safest default for the type if we receive a =
> plain java.util.Date? Which implicit SQL type will work with most =
> databases in a predictable manner?
> =20
> Juergen
> =20
>
> ________________________________
>
> Von: spr...@li... im Auftrag =
> von tho...@tr...
> Gesendet: Di 31.08.2004 22:56
> An: spr...@li...
> Betreff: Re: [Springframework-developer] StatementCreatorUtils
>
>
>
> Wouldn't java.sql.Timestamp be a better choice for java.util.Date and
> java.util.Calendar with unknow SQL type?  That way you would not lose =
> the time
> portion.
>
> Thomas
>
>
> Quoting "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>:
>
> > I've adapted StatementCreatorUtils as follows:
> >
> > * StatementCreatorUtils uses specific PreparedStatement parameter =
> setter =3D
> > methods, as far as possible
> > * added auto-conversion of java.util.Calendar to =3D
> > java.sql.Date/Time/Timestamp, for SQL types DATE/TIME/TIMESTAMP
> > * added auto-conversion of java.util.Date and java.util.Calendar to =
> =3D
> > java.sql.Date, in case of an unknown SQL type
> >
> > This was partly triggered by
> > http://opensource.atlassian.com/projects/spring/browse/SPR-301
> >
> > Thomas and co, please give the new version a try. It should =
> essentially =3D
> > work the same as before, just do a few more auto-conversions.
> >
> > Juergen
> >
> >
> > -------------------------------------------------------
> > 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
> >
>
>
>
>
>
> -------------------------------------------------------
> 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
>
>
>
>
> -------------------------------------------------------
> 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=5047&alloc_id=10808&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>

Re: [Springframework-developer] flush() method on HibernateTemplate

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

Well, that's what HibernateTemplate's FLUSH_EAGER mode is meant for: To =
automatically flush right after each operation, even if a prebound =
Session is used. I would generally recommend to use such a preconfigured =
HibernateTemplate instance here, no matter if a shared one like in a =
HibernateDaoSupport or a newly instantiated one for a given =
SessionFactory.
=20
I'm not keen on a flush operation on HibernateTemplate itself: That's =
not really a data access operation like the other methods there, but =
rather a method that just modifies the state of the transaction. If =
someone doesn't like the approach with a preconfigured =
HibernateTemplate, there's still the option of a custom =
HibernateCallback, even if just for a save and a flush.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Mi 01.09.2004 17:34
An: spr...@li...
Betreff: [Springframework-developer] flush() method on HibernateTemplate



Juergen,

We had a request on the forums (and I've seen this before) to add
flush() as a method on HibernateTemplate. Of course, this would be
completely useless (or superfluous) in the case there is no existing
thread bound session (or at least an existing outer transaction to bind
the new session to and keep it there afterwards). But most people do use
HibernateTemplate in their DAOs with the expectation that the Session is
already around or will be created and stay around, and it's probably
reasonable to allow them to do a flush without having to use
HibernateCallback, since they could have just done a one-off operation
like save() and then want to ensure that changes go out, for example
when combining with JDBC based operations in a DAO.

What do you think?






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

Re: [Springframework-developer] JTA transaction suspension on WebSphere

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

An update: The issue was indeed caused by Spring's transaction =
synchronization in combination with EJB CMT transaction suspension. Once =
you turn off Spring's transaction synchronization, which causes our =
Hibernate support to fall back to direct JTA synchronization, everything =
works nicely. I've also refined our Hibernate LOB types to be able to =
work with direct JTA synchronization too, so that our full Hibernate =
support works in such a scenario without hassle.
=20
Furthermore, Victor was so kind to test a variety of combinations with =
Spring-driven JTA transaction suspension on WebSphere, among those with =
an outer transaction that has been marked rollback-only (which doesn't =
work out-of-the-box on WebLogic). Fortunately, everything worked nicely!
=20
Thus, it's now quite safe to assume that WebSphere's JTA =
TransactionManager is fully compatible with Spring, at least on =
WebSphere 4. It would be good to get some tests on WebSphere 5 - any =
volunteers? This means, to the best of our current knowledge, that we =
only need special handling (WebLogicJtaTransactionManager) on WebLogic, =
and that the only container where suspend/resume doesn't work in all =
cases is WebLogic 7.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Di 31.08.2004 10:58
An: spr...@li...
Betreff: Re: [Springframework-developer] JTA transaction suspension on =
WebSphere



Indeed, Thomas: I've pointed out exactly the same to Eugene on that =
WebLogic issue in JIRA.

FYI, I've just noticed that I might have misinterpreted Victor's problem =
last night: He doesn't use Spring transactions with REQUIRES_NEW, but =
rather an outer Spring transaction plus an inner EJB CMT transaction =
with REQUIRES_NEW. Spring's JtaTransactionManager never touches the JTA =
TransactionManager is such a scenario, so it can't be caused by the =
suspend/resume interaction there.

I rather suspect that the problem is Spring's transaction =
synchronization, which gets activated for the outer Spring transaction, =
but doesn't get notified of the transaction suspension caused by the =
inner EJB CMT transaction. Therefore, Spring's Hibernate support within =
the inner transaction will still synchronize with the outer Spring =
transaction, flushing the Hibernate Session at completion of the *outer* =
rather than the inner transaction.

The solution I've suggested is to turn off Spring's transaction =
synchronization in that case. It should always be turned off when using =
transaction suspension driven by EJB CMT. See my JIRA comments:

http://opensource.atlassian.com/projects/spring/browse/SPR-295

As I've noted there, it would still be interesting whether Spring-driven =
JTA transaction suspension works with WebSphere: i.e., a Spring =
transaction demarcation with REQUIRES_NEW in case of an existing =
transaction. We might still face problems there, of course, but it seems =
to me that Victor's issue is not an indication for those.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Thomas Risberg
Gesendet: Di 31.08.2004 06:33
An: spr...@li...
Betreff: Re: [Springframework-developer] JTA transaction suspension on =
WebSphere



This is not an issue for transactions declared with REQUIRED, SUPPORTS,
MANDATORY or NEVER.  For these transactions there is no need to mess
with the JTA TransactionManager to suspend the current transaction.
UserTransaction is sufficient for these and this should be portable
between containers.

The only trouble is with REQUIRES_NEW and NOT_SUPPORTED.  Here we have
to bend the rules and use the JTA TransactionManager API if it is
available.  This is where things break down since the appservers don't
seem to cooperate.  Even WebLogic 8.1 did not work until we used a
WebLogic specific API call (forceResume).

Thomas


Colin Sampaleanu wrote:

> Eugene Kuleshov wrote:
>
>> Colin Sampaleanu wrote:
>>
>>> 'Eu' on his blog 3-4 days ago commented based on my own blog entry,
>>> and a forum message:
>>>  =
http://jroller.com/page/eu/20040826#using_spring_jta_interfaces_from
>>> that section / C.2.4 /of the EJB spec says that the container, for
>>> EJBs, must implement the UserTransaction interface (and JTA 1.0.1)
>>> extension, but doesn't have to implement the other interfaces
>>> defined in the JTA specification. Fine, I've actually seen that
>>> before, coincidentally, when I was tracking something down a while
>>> ago, but I think a container is fundamentally broken if it _does_
>>> expose the JTA TransactionManager interface, and it doesn't behave
>>> as per the spec. The spec for an API is the spec for the API. If you
>>> expose the interface at all, then you need to expose it correctly...
>>> That's essentially how I read that clause, and how I see things. In
>>> any case, I hope the situation is going to improve, certainly WLS 8
>>> works where WLS 7 doesn't, with out WL specific adapter...
>>
>>
>>
>>   Perhaps I wasn't clear enough. My point is that it is a bad idea to
>> mix usage of JTA interface with declarative container managed
>> transacttions for EJBs. In other words it is probably to use Spring
>> JTA helpers/wrappers in web layer which is not using EJB's.
>>
>>   Anyway it would be good have some more advanced tests to ensure
>> that JTA actually work in WLS8 (and other containers) in case of
>> failure/rollback with multiple XA resources involved into transaction
>> (especially resources from different vendors, such as Oracle, Sybase,
>> MQSeries).
>
>
> I fully agree about the tests. This is part of the reason I created
> the ejbtest integration sample. Hopefully we will keep adding to it.
>
> As for the clause in question, it says:
>
> "The EJB container must include the JTA 1.0.1 extension, and it must
> provide the javax.transaction.UserTransaction interface to  enterprise
> beans with bean-managed transaction demarcation through the
> javax.ejb.EJBContext interface, and also in JNDI under the name
> java:comp/UserTransaction, in the cases required by the EJB
> specification.
> The other JTA interfaces are low-level transaction manager and
> resource manager integration interfaces, and are not intended for
> direct use by enterprise beans.
>
> This is unfortunately not worded very well in my opinion, in terms of
> being very clear about CMT. Consider that this is the section of the
> spec called 'The Container Provider's Responsibility'. It is about the
> minimum set of services which the container must provide to the EJB. I
> do not equate anything in the paragraphs above as saying (with any
> adequate level of clarity) that if the container chooses to expose
> other APIs the EJB _is not_ allowed to use them. I read the last
> sentence as a justification as to _why_ the container doesn't have to
> provide the other JTA interfaces. The spec is actually very specific
> about what EJBs may and may not do, consider threading for example.
> Again, my opinion is that if the container does choose to expose an
> API like JTA's TransactionManager, then it has to behave correctly, as
> an API is an API.
>
> Ultimately, only the spec writers know what they really intended, and
> I agree that people wanting to move an app from container to
> container, and from app server version to version, are not going to
> get as predictable results in a CMT+Spring Transaction setup as they
> would in a CMT alone, or Spring Tx alone setup. That said, it can
> still be a viable and useful combination. Over a period of some
> months, I migrated an app on JBoss from CMT EJB to no EJB with Spring
> Tx wrapping service beans, and the CMT+Spring Tx combo provided a
> valuable middle ground in the migration, in the perdio when there were
> still some EJBs, but a lot had already moved over.
>
> Regards,
> Colin
>
>
>
>
> -------------------------------------------------------
> 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
>
>
>



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




-------------------------------------------------------
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_idP47&alloc_id=10808&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Chain of Resposibilty Controllers or Handlers

[THOMAS, J. (SBCSI) <jt...@sb...>]

Hello All,
Is there any plan to implement the ability for the Dispatcher Servlet to
handle a chain of handlers for a particular request. 
Thanks
Jayant

[Springframework-developer] flush() method on HibernateTemplate

[Colin S. <col...@ex...>]

Juergen,

We had a request on the forums (and I've seen this before) to add 
flush() as a method on HibernateTemplate. Of course, this would be 
completely useless (or superfluous) in the case there is no existing 
thread bound session (or at least an existing outer transaction to bind 
the new session to and keep it there afterwards). But most people do use 
HibernateTemplate in their DAOs with the expectation that the Session is 
already around or will be created and stay around, and it's probably 
reasonable to allow them to do a flush without having to use 
HibernateCallback, since they could have just done a one-off operation 
like save() and then want to ensure that changes go out, for example 
when combining with JDBC based operations in a DAO.

What do you think?