You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(55) |
Mar
(100) |
Apr
(203) |
May
(330) |
Jun
(190) |
Jul
(302) |
Aug
(323) |
Sep
(197) |
Oct
(245) |
Nov
(490) |
Dec
(330) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(194) |
Feb
(400) |
Mar
(416) |
Apr
(415) |
May
(359) |
Jun
(381) |
Jul
(491) |
Aug
(311) |
Sep
(291) |
Oct
(273) |
Nov
(355) |
Dec
(266) |
| 2005 |
Jan
(306) |
Feb
(303) |
Mar
(520) |
Apr
(346) |
May
(255) |
Jun
(221) |
Jul
(171) |
Aug
(247) |
Sep
(147) |
Oct
(125) |
Nov
(165) |
Dec
(65) |
| 2006 |
Jan
(90) |
Feb
(53) |
Mar
(121) |
Apr
(103) |
May
(113) |
Jun
(103) |
Jul
(104) |
Aug
(67) |
Sep
(78) |
Oct
(82) |
Nov
(78) |
Dec
(70) |
| 2007 |
Jan
(77) |
Feb
(76) |
Mar
(63) |
Apr
(30) |
May
(47) |
Jun
(41) |
Jul
(44) |
Aug
(44) |
Sep
(49) |
Oct
(33) |
Nov
(25) |
Dec
(21) |
| 2008 |
Jan
(45) |
Feb
(13) |
Mar
(15) |
Apr
(12) |
May
(9) |
Jun
(33) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(17) |
Nov
(20) |
Dec
(10) |
| 2009 |
Jan
(8) |
Feb
(5) |
Mar
(12) |
Apr
(17) |
May
(19) |
Jun
(97) |
Jul
(77) |
Aug
(33) |
Sep
(24) |
Oct
(41) |
Nov
(16) |
Dec
(32) |
| 2010 |
Jan
(24) |
Feb
(14) |
Mar
(50) |
Apr
(71) |
May
(70) |
Jun
(64) |
Jul
(45) |
Aug
(62) |
Sep
(32) |
Oct
(4) |
Nov
(12) |
Dec
(2) |
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(6) |
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(4) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
| 2012 |
Jan
(4) |
Feb
(8) |
Mar
(6) |
Apr
(10) |
May
(2) |
Jun
(3) |
Jul
(11) |
Aug
(10) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
(9) |
Apr
(1) |
May
(8) |
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(10) |
Dec
(8) |
| 2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(12) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(9) |
May
(2) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(7) |
Oct
(9) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(5) |
Apr
(5) |
May
(8) |
Jun
(4) |
Jul
(5) |
Aug
(4) |
Sep
(6) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
| 2017 |
Jan
(7) |
Feb
(8) |
Mar
(7) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(8) |
Sep
(4) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2026 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Raj P. <coo...@gm...> - 2005-06-29 17:27:34
|
Hibernate 3.0 has improved support for session management, including automatic session management/flushing in transactions: http://www.hibernate.org/hib_docs/v3/reference/en/html/session-configuratio= n.html#configuration-j2ee-currentsession Have you guys thought about letting hibernate manage this instead of having extra code in Spring to manage this? Raj |
|
From: Roland H. <Rol...@co...> - 2005-06-29 06:15:58
|
Hi,
In MetadataMBeanInfoAssembler:
protected void populateAttributeDescriptor(....) {
[...]
String persistPolicy = resolveStringDescriptor(
gma.getPersistPolicy(), sma.getPersistPolicy(), PERSIST_POLICY_NEVER);
desc.setField(FIELD_PERSIST_POLICY, persistPolicy);
[...]
}
IMHO, if there is no 'persistPolicy' set on an JMX attribute via a ManagedAttribute
annotation, the persistPolicy should be inherited from the ManagedResource annotation and
*not* set to PERSIST_POLICY_NEVER by default. A solution would be not to call
'desc.setField()' if no persistPolicy is set for an attribute, since JMX will pick up the
one provided for the MBean.
Or am I wrong ?
ciao....
--
...roland huss
consol.de
|
|
From: <al...@in...> - 2005-06-28 22:28:50
|
View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050629001616Lbuild.293 |
|
From: John L. <jl...@ar...> - 2005-06-28 22:21:51
|
I just posted some code from our initial integration of Acegi with the JSR-168 compliant Spring Portlet MVC Framework. You can see the code here: http://forum.springframework.org/viewtopic.php?p=26141 I'm interested in any feedback on this, including if something along these lines should be formally included somewhere. John Lewis jl...@ar... |
|
From: <al...@in...> - 2005-06-28 00:52:21
|
View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050628001633Lbuild.292 |
|
From: Colin S. <col...@ex...> - 2005-06-28 00:07:12
|
I've added documentation for the Transactional Java 5 Annotation (supported since Spring 1.2), in the section on transactions, and slightly tweaked the chapter on source metadata (mostly talking about the Attributes abstraction and commons-attributes) so it doesn't talk about Java 5 annotations as a future thing. -- Colin Sampaleanu Interface21 Principal Consultant Spring Training, Consulting and Support - "From the Source" http://www.springframework.com |
|
From: Keith D. <ke...@in...> - 2005-06-27 22:27:20
|
I'm in the process of building in jmx manageability to webflow - specifically adding global flow statistics capability as well as the ability to monitor individual flow executions. I was wondering how Spring JMX could best help me here. Right now I have a "StatisticsService" which takes a FlowExecutionManager (the entry point for managing all flows of the app, and for attaching listeners). When the stats service is initialized, I'm thinking it should do its own registration of a global statistics mbean, and deregistering on shtutdown. It'll also attach a stats listener, which will register new mbeans for flow executions that are spawned and clean them up when they're shut down. In essence, I think what I could use is some JMXTemplate type stuff - to help with mbean registration/deregistration in a MBeanServer. What do you think? Keith -- Keith Donald Interface21 Principal Consultant http://www.springframework.com <http://www.springframework.com/> |
|
From: Juergen H. <ju...@in...> - 2005-06-27 18:05:32
|
We currently expect 1.3 RC1 to be released in September. The scope is already 90% fixed, so I don't expect any significant delays there. That said, some of the enhancement requests in JIRA are under = consideration for 1.2.3, provided that their effect on backwards compatibility is manageable. We're just not promising that they are gonna make their way = into a 1.2.x release :-) Juergen =20 -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of Boyce, Keith Garry Sent: Monday, June 27, 2005 7:53 PM To: spr...@li... Subject: RE: [Springframework-developer] 1.2.2 Timeframe? Is there any timeframe cof 1.3 RC1? -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of Juergen Hoeller Sent: Monday, June 27, 2005 1:46 PM To: spr...@li... Subject: Re: [Springframework-developer] 1.2.2 Timeframe? 1.2.2 will be out any day now. It's actually slightly behind schedule, mainly caused by connectivity issues here in San Francisco (at JavaOne), = but also by some last-minute fixes making their way into the release. Regarding your issue: a change there has quite a bit of effect on = various things, so it's beyond 1.2.2, and probably even beyond any 1.2.x = release. Hence, I've currently scheduled it for 1.3 RC1. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of Boyce, Keith Garry Sent: Monday, June 27, 2005 3:12 PM To: spr...@li... Subject: [Springframework-developer] 1.2.2 Timeframe? What's the timeframe for 1.2.2? Do you think you will get to http://opensource.atlassian.com/projects/spring/browse/SPR-1076 before = that release? -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of Juergen Hoeller Sent: Monday, June 27, 2005 2:57 AM To: spr...@li... Subject: RE: [Springframework-developer] questions on highlighting two issues in JIRA. Tim, Thanks for the reminder. Those issues simply fell through the cracks = during 1.2.2 preparations. I've just addressed both of them as last-minute = fixes for Spring 1.2.2. Juergen This message is a PRIVATE communication. If you are not the intended recipient, please do not read, copy, or use = it, and do not disclose it to others. Please notify the sender of the = delivery error by replying to this message, and then delete it from your system. Thank you. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies = from IBM. Find simple to follow Roadmaps, straightforward articles, = informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies = from IBM. Find simple to follow Roadmaps, straightforward articles, = informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer This message is a PRIVATE communication. If you are not the intended recipient, please do not read, copy, or use = it, and do not disclose it to others. Please notify the sender of the = delivery error by replying to this message, and then delete it from your system. Thank you. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies = from IBM. Find simple to follow Roadmaps, straightforward articles, = informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Boyce, K. G. <Kei...@bc...> - 2005-06-27 17:52:49
|
Is there any timeframe cof 1.3 RC1?=0D -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Juergen Hoeller Sent: Monday, June 27, 2005 1:46 PM To: spr...@li... Subject: Re: [Springframework-developer] 1.2.2 Timeframe? 1.2.2 will be out any day now. It's actually slightly behind schedule, mainly caused by connectivity issues here in San Francisco (at JavaOne), but also by some last-minute fixes making their way into the release. Regarding your issue: a change there has quite a bit of effect on various things, so it's beyond 1.2.2, and probably even beyond any 1.2.x release. Hence, I've currently scheduled it for 1.3 RC1. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Boyce, Keith Garry Sent: Monday, June 27, 2005 3:12 PM To: spr...@li... Subject: [Springframework-developer] 1.2.2 Timeframe? What's the timeframe for 1.2.2? Do you think you will get to http://opensource.atlassian.com/projects/spring/browse/SPR-1076 before that release? -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Juergen Hoeller Sent: Monday, June 27, 2005 2:57 AM To: spr...@li... Subject: RE: [Springframework-developer] questions on highlighting two issues in JIRA. Tim, Thanks for the reminder. Those issues simply fell through the cracks during 1.2.2 preparations. I've just addressed both of them as last-minute fixes for Spring 1.2.2. Juergen This message is a PRIVATE communication. If you are not the intended recipient, please do not read, copy, or use it, and do not disclose it to others. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer This message is a PRIVATE communication. If you are not the intended recipient, please do not read, copy, or use it, and do not disclose it to others. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you. |
|
From: Juergen H. <ju...@in...> - 2005-06-27 17:46:58
|
1.2.2 will be out any day now. It's actually slightly behind schedule, mainly caused by connectivity issues here in San Francisco (at JavaOne), = but also by some last-minute fixes making their way into the release. Regarding your issue: a change there has quite a bit of effect on = various things, so it's beyond 1.2.2, and probably even beyond any 1.2.x = release. Hence, I've currently scheduled it for 1.3 RC1. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of Boyce, Keith Garry Sent: Monday, June 27, 2005 3:12 PM To: spr...@li... Subject: [Springframework-developer] 1.2.2 Timeframe? What's the timeframe for 1.2.2? Do you think you will get to http://opensource.atlassian.com/projects/spring/browse/SPR-1076 before = that release? -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of Juergen Hoeller Sent: Monday, June 27, 2005 2:57 AM To: spr...@li... Subject: RE: [Springframework-developer] questions on highlighting two issues in JIRA. Tim, Thanks for the reminder. Those issues simply fell through the cracks = during 1.2.2 preparations. I've just addressed both of them as last-minute = fixes for Spring 1.2.2. Juergen This message is a PRIVATE communication. If you are not the intended recipient, please do not read, copy, or use = it, and do not disclose it to others. Please notify the sender of the = delivery error by replying to this message, and then delete it from your system. Thank you. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies = from IBM. Find simple to follow Roadmaps, straightforward articles, = informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Boyce, K. G. <Kei...@bc...> - 2005-06-27 13:12:05
|
What's the timeframe for 1.2.2? Do you think you will get to http://opensource.atlassian.com/projects/spring/browse/SPR-1076 before that release? =0D -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Juergen Hoeller Sent: Monday, June 27, 2005 2:57 AM To: spr...@li... Subject: RE: [Springframework-developer] questions on highlighting two issues in JIRA. Tim, Thanks for the reminder. Those issues simply fell through the cracks during 1.2.2 preparations. I've just addressed both of them as last-minute fixes for Spring 1.2.2. Juergen =0D This message is a PRIVATE communication. If you are not the intended recipient, please do not read, copy, or use it, and do not disclose it to others. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you. |
|
From: Juergen H. <ju...@in...> - 2005-06-27 08:44:19
|
As per my latest comment on your other issue, this will work now for = beans with factory method as well, provided that they are defined as = singleton: Once a bean with a factory method has been instantiated, its type _is_ = known and correctly detected by "getType", "getBeanNamesOfType" and "getBeansOfType".=20 I've just further refined AbstractBeanFactory to actually trigger instantiation of a bean with a factory method even when just determining = the type - provided that the target bean is a singleton. The BeanFactory = already behaves similarly for beans that implement the FactoryBean interface. For prototype beans with factory method declaration, the type will still = be considered undeterminable, which I think is acceptable. Juergen =20 -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf = Of Tim Diggins Sent: Monday, June 27, 2005 10:05 AM To: spr...@li... Subject: Re: [Springframework-developer] autowire by type on a = factory-bean factory-method I understand that getType on any factory-method type bean returns Null, implying that autowire by type wouldn't work with one of these. Getting = the getType to check the type of the bean returned by factory-method is not = that difficult (just a bit of introspection), but isn't (as I understand it) underway at present. This is paraphrased & deduced from a recent comment on JIRA http://opensource.atlassian.com/projects/spring/browse/SPR-1011 Tim Keith Donald wrote: > Autowire by type on a factory-bean factory-method doesn't seem=20 > supported. I noticed this in a dependency injection-enabled spring=20 > test, where I wanted to auto-inject the result of a factory method. > Would this be difficult to do? >=20 > =20 >=20 > Keith >=20 > =20 >=20 > -- > Keith Donald > Interface21 Principal Consultant >=20 > http://www.springframework.com <http://www.springframework.com/> >=20 > =20 >=20 ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies = from IBM. Find simple to follow Roadmaps, straightforward articles, = informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Tim D. <sub...@re...> - 2005-06-27 08:05:36
|
I understand that getType on any factory-method type bean returns Null,=20 implying that autowire by type wouldn't work with one of these. Getting=20 the getType to check the type of the bean returned by factory-method is=20 not that difficult (just a bit of introspection), but isn't (as I=20 understand it) underway at present. This is paraphrased & deduced from a recent comment on JIRA http://opensource.atlassian.com/projects/spring/browse/SPR-1011 Tim Keith Donald wrote: > Autowire by type on a factory-bean factory-method doesn=92t seem=20 > supported. I noticed this in a dependency injection-enabled spring=20 > test, where I wanted to auto-inject the result of a factory method.=20 > Would this be difficult to do? >=20 > =20 >=20 > Keith >=20 > =20 >=20 > --=20 > Keith Donald > Interface21 Principal Consultant >=20 > http://www.springframework.com <http://www.springframework.com/> >=20 > =20 >=20 |
|
From: Juergen H. <ju...@in...> - 2005-06-27 06:57:41
|
Tim, Thanks for the reminder. Those issues simply fell through the cracks during 1.2.2 preparations. I've just addressed both of them as last-minute fixes for Spring 1.2.2. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Tim Diggins Sent: Friday, June 24, 2005 4:52 PM To: spr...@li... Cc: spr...@li... Subject: [Springframework-developer] questions on highlighting two issues in JIRA. Hi all - I put two issues in JIRA a few weeks ago: Bug SPR-1011 http://opensource.atlassian.com/projects/spring/browse/SPR-1011 Static factory-method instantiated beans can break type-safety. UNRESOLVED 04/Jun/05 04/Jun/05 Bug SPR-1010 http://opensource.atlassian.com/projects/spring/browse/SPR-1010 Instance Factory initialised Beans not created. UNRESOLVED 04/Jun/05 04/Jun/05 The reports included even testcases demonstrating the problems as I saw them. I'm happy to try to work on a "fix" for them if appropriate, but could do with: a) a heads-up as to whether these are indeed problems, or if they are somehow my misunderstandings (I'm pretty new at using Spring) b) some kind of suggestion of where I might look for solutions(having looked at the similar (though not equivalent) tests in the spring-cvs hasn't really helped) If, on the other hand, I'm not posting the problems in a useful format, or whatever, then please let me know. After posting (in JIRA, on springframework-user and in the online forums) and getting nothing, leaves me a bit dispirited - any kind of comment (even very negative) would be more useful. Many thanks Tim Sent this to springframework-developer and springframework-user. Not sure which one this qualifies as. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <al...@in...> - 2005-06-25 22:29:16
|
View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050626001701Lbuild.291 |
|
From: Michael E. M. <mm...@re...> - 2005-06-25 20:28:19
|
sorry, wrong list.... Dmitriy Kopylenko wrote: > Seems like a question for Hibernate folks. > > Dmitriy. > > Michael E. Moores wrote: > >> an odd looking exception appears when i load this named query: >> >> <query >> name="CreditAccountTransaction.setPendingAuthorizationToExpired"><![CDATA[ >> >> update CreditTransaction set status = 'Expired', >> updateTime = :time >> where status = 'Pending' >> and authorizationExpireTime < :time >> ]]> >> </query> >> >> >> [junit] org.springframework.beans.factory.BeanCreationException: >> Error creating bean with name 'sessionFactory' defined in file >> [/home/mmoores/rnwk/cvs/app/creditmgr2/test/config/../../config/data-access-springcontext.xml]: >> Initialization of bean failed; nested exception is >> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 >> [junit] java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 >> [junit] at java.util.ArrayList.RangeCheck(ArrayList.java:547) >> [junit] at java.util.ArrayList.get(ArrayList.java:322) >> [junit] at >> org.hibernate.hql.ast.HqlSqlWalker.postProcessUpdate(HqlSqlWalker.java:390) >> >> [junit] at >> org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:164) >> >> [junit] at >> org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:189) >> >> [junit] at >> org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:130) >> >> [junit] at >> org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:83) >> >> [junit] at >> org.hibernate.impl.SessionFactoryImpl.getQuery(SessionFactoryImpl.java:427) >> >> [junit] at >> org.hibernate.impl.SessionFactoryImpl.checkNamedQueries(SessionFactoryImpl.java:388) >> >> [junit] at >> org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:291) >> >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >> from IBM. Find simple to follow Roadmaps, straightforward articles, >> informative Webcasts and more! Get everything you need to get up to >> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Keith D. <ke...@in...> - 2005-06-25 19:27:13
|
Autowire by type on a factory-bean factory-method doesn't seem supported. I noticed this in a dependency injection-enabled spring test, where I wanted to auto-inject the result of a factory method. Would this be difficult to do? Keith -- Keith Donald Interface21 Principal Consultant http://www.springframework.com <http://www.springframework.com/> |
|
From: Dmitriy K. <dko...@ru...> - 2005-06-25 12:34:55
|
Seems like a question for Hibernate folks. Dmitriy. Michael E. Moores wrote: > an odd looking exception appears when i load this named query: > > <query > name="CreditAccountTransaction.setPendingAuthorizationToExpired"><![CDATA[ > > update CreditTransaction set status = 'Expired', > updateTime = :time > where status = 'Pending' > and authorizationExpireTime < :time > ]]> > </query> > > > [junit] org.springframework.beans.factory.BeanCreationException: > Error creating bean with name 'sessionFactory' defined in file > [/home/mmoores/rnwk/cvs/app/creditmgr2/test/config/../../config/data-access-springcontext.xml]: > Initialization of bean failed; nested exception is > java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > [junit] java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > [junit] at java.util.ArrayList.RangeCheck(ArrayList.java:547) > [junit] at java.util.ArrayList.get(ArrayList.java:322) > [junit] at > org.hibernate.hql.ast.HqlSqlWalker.postProcessUpdate(HqlSqlWalker.java:390) > > [junit] at > org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:164) > > [junit] at > org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:189) > > [junit] at > org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:130) > > [junit] at > org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:83) > > [junit] at > org.hibernate.impl.SessionFactoryImpl.getQuery(SessionFactoryImpl.java:427) > > [junit] at > org.hibernate.impl.SessionFactoryImpl.checkNamedQueries(SessionFactoryImpl.java:388) > > [junit] at > org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:291) > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Michael E. M. <mm...@re...> - 2005-06-25 04:25:55
|
an odd looking exception appears when i load this named query:
<query
name="CreditAccountTransaction.setPendingAuthorizationToExpired"><![CDATA[
update CreditTransaction
set status = 'Expired',
updateTime = :time
where status = 'Pending'
and authorizationExpireTime < :time
]]>
</query>
[junit] org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'sessionFactory' defined in file
[/home/mmoores/rnwk/cvs/app/creditmgr2/test/config/../../config/data-access-springcontext.xml]:
Initialization of bean failed; nested exception is
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
[junit] java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
[junit] at java.util.ArrayList.RangeCheck(ArrayList.java:547)
[junit] at java.util.ArrayList.get(ArrayList.java:322)
[junit] at
org.hibernate.hql.ast.HqlSqlWalker.postProcessUpdate(HqlSqlWalker.java:390)
[junit] at
org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:164)
[junit] at
org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:189)
[junit] at
org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:130)
[junit] at
org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:83)
[junit] at
org.hibernate.impl.SessionFactoryImpl.getQuery(SessionFactoryImpl.java:427)
[junit] at
org.hibernate.impl.SessionFactoryImpl.checkNamedQueries(SessionFactoryImpl.java:388)
[junit] at
org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:291)
|
|
From: <al...@in...> - 2005-06-24 22:28:51
|
View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050625001628Lbuild.290 |
|
From: Farhan K. <ka...@gm...> - 2005-06-24 21:01:44
|
We have web application that uses Spring to manage business tier components. We also have a few MDBs that need to leverage the same business tier components as well. The question I have is: is there a way to place the entire Spring ApplicationContext on the JNDI of our WebSphere server, and have it accessible from both our EJBs and web application? I'll appreciate any responses. |
|
From: Juergen H. <ju...@in...> - 2005-06-24 17:17:08
|
As I said a couple of days ago, the potential for follow-up errors has been
removed: no dangling thread-bound resource can remain in any case now, not
even in case of internal assertion failures.
Why that assertion (that you encountered) failed in the first place is still
unclear. But at least the effect of such an assertion failure has been
reduced to the transaction that caused it now.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Dave Ballard
Sent: Friday, June 24, 2005 6:47 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Stale JTA transaction still
attached to a thread
Hi Juergen,
Any thoughts on this? It hasn't happened again since I reported it.
Dave
Dave Ballard wrote:
> Hi Juergen,
>
> There was a failure involving the Spring transactional cleanup code
> which may be of interest.
>
> Background: My application architecture is in transition from
> stateless session beans (for transaction demarcation) and entity
> beans, to Spring managed services (and transaction demarcation) and
> dao's. So currently, I've got a mix of both. In some cases, I've got a
> session bean starting a transaction, then that session bean calling a
> Spring service (resulting in the JTA transaction being joined). In
> other newer code, Spring starts the transaction.
>
> The thread in question is ExecuteThread: '5'. The first sign of
> trouble with this thread is a failure of an insert statement. I've
> seen this 'PreparedStatement' exception once before a number of months
> ago. I don't *think* this is a Hibernate bug, as the last time the
> error involved an entity bean. It may be a problem with my JDBC driver.
>
> Spring didn't start this transaction, but at this point in processing,
> SessionFactoryUtils.getSession(sessionFactory, true) has been called
> from the session bean, and a Spring managed service (with a
> JtaTransactionManager transaction interceptor) has also been called.
>
> ---
> ERROR 13:34:55,789 [ExecuteThread: '5' for queue: 'default'] [mariew_]
> (MoneyTransactionSessionEJB.java:459) - Error creating advance
> net.sf.hibernate.JDBCException: could not insert:
> [LedgerEntryClass#LEN000061465159]
> at
> net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java
> :478)
>
> at
> net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java
> :442)
>
> at
> net.sf.hibernate.impl.ScheduledInsertion.execute(ScheduledInsertion.ja
> va:29)
>
> at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2414)
> at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2367)
> at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2236)
> at
> MoneyTransactionSessionEJB.createLedgerEntriesForNewContractItems(Mone
> yTransactionSessionEJB.java:5661)
>
> at
> MoneyTransactionSessionEJB.processTransactionInternal(MoneyTransaction
> SessionEJB.java:704)
>
> at
> MoneyTransactionSessionEJB.processTransaction(MoneyTransactionSessionE
> JB.java:454)
>
> at
> MoneyTransactionSessionEJB_xvjdlx_ELOImpl.processTransaction(MoneyTran
> sactionSessionEJB_xvjdlx_ELOImpl.java:1037)
>
> at java.lang.reflect.Method.invoke(Native Method)
> at
> org.springframework.ejb.access.LocalSlsbInvokerInterceptor.invoke(Loca
> lSlsbInvokerInterceptor.java:66)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(R
> eflectiveMethodInvocation.java:144)
>
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamic
> AopProxy.java:174)
>
> at $Proxy126.processTransaction(Unknown Source)
> at AdvanceCreate.execute(AdvanceCreate.java:109)
> at AdvanceCommit.createAdvance(AdvanceCommit.java:368)
> at AdvanceCommit.process(AdvanceCommit.java:118)
> at
> jsp_servlet._jsp._advance.__advance_confirm._jspService(__advance_conf
> irm.java:125)
>
> at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImp
> l.java:275)
>
> at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.jav
> a:27)
>
> at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
> at AccessControlFilter.doFilter(AccessControlFilter.java:79)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.jav
> a:27)
>
> at
> weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSer
> vletContext.java:2708)
>
> at
> weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImp
> l.java:2427)
>
> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:159)
> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:140)
> Caused by:
> java.sql.SQLException: [JTurbo 3.1d9 JDBC 2.1 Driver]:
> PreparedStatement is closed
> at com.newatlanta.jturbo.driver.u.executeUpdate(u.java)
> at weblogic.jdbc.jts.Statement.executeUpdate(Statement.java:508)
> at
> net.sf.hibernate.impl.NonBatchingBatcher.addToBatch(NonBatchingBatcher
> .java:22)
>
> at
> net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java
> :468)
>
> ... 29 more
> ---
>
> One minute later, this same thread was used for a different request
> (the username is different):
>
> ---
> ERROR 13:35:56,805 [ExecuteThread: '5' for queue: 'default'] [dan101_]
> (AbstractPlatformTransactionManager.java:585) - Rollback exception
> overridden by synchronization exception
> java.lang.IllegalStateException: No value for key
> [net.sf.hibernate.impl.SessionFactoryImpl@55f3ea] bound to thread
> [ExecuteThread: '5' for queue: 'default']
> at
> org.springframework.transaction.support.TransactionSynchronizationMana
> ger.unbindResource(TransactionSynchronizationManager.java:175)
>
> at
> org.springframework.orm.hibernate.SessionFactoryUtils$SpringSessionSyn
> chronization.beforeCompletion(SessionFactoryUtils.java:871)
>
> at
> org.springframework.transaction.support.AbstractPlatformTransactionMan
> ager.triggerBeforeCompletion(AbstractPlatformTransactionManager.java:5
> 80)
>
> at
> org.springframework.transaction.support.AbstractPlatformTransactionMan
> ager.commit(AbstractPlatformTransactionManager.java:425)
>
> at
> org.springframework.transaction.interceptor.TransactionAspectSupport.d
> oCommitTransactionAfterReturning(TransactionAspectSupport.java:258)
>
> at
> org.springframework.transaction.interceptor.TransactionInterceptor.inv
> oke(TransactionInterceptor.java:67)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(R
> eflectiveMethodInvocation.java:144)
>
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamic
> AopProxy.java:174)
>
> at $Proxy114.findContract(Unknown Source)
> at AdvanceView.load(AdvanceView.java:228)
> at AdvanceView.process(AdvanceView.java:141)
> at
> jsp_servlet._jsp._advance.__advanceview._jspService(__advanceview.java
> :139)
>
> at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImp
> l.java:275)
>
> at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.jav
> a:27)
>
> at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
> at AccessControlFilter.doFilter(AccessControlFilter.java:79)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.jav
> a:27)
>
> at
> weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatc
> herImpl.java:289)
>
> at
> webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:222)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImp
> l.java:275)
>
> at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.jav
> a:27)
>
> at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
> at AccessControlFilter.doFilter(AccessControlFilter.java:79)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.jav
> a:27)
>
> at
> weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatc
> herImpl.java:289)
>
> at
> weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:119)
> at
> jsp_servlet._jsp._advance.__advance_confirm._jspService(__advance_conf
> irm.java:165)
>
> at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImp
> l.java:275)
>
> at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.jav
> a:27)
>
> at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
> at AccessControlFilter.doFilter(AccessControlFilter.java:79)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.jav
> a:27)
>
> at
> weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSer
> vletContext.java:2708)
>
> at
> weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImp
> l.java:2427)
>
> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:159)
> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:140)
> ---
> There are no nested exceptions. In the previous stack trace, the
> presentation layer called a Spring managed service (which started its
> own transaction).
> After this point, each time ExecuteThread: '5' is used, it fails
> with a org.springframework.jdbc.UncategorizedSQLException wrapping a
> WebLogic TimedOutException. The transaction ID (496219) is always the
> same. This happens over and over again. As I was investigating this
> problem, I began to ask myself "why are all of these timeouts on the
> same thread?". Restarting the app server corrected the problem. The
> timeout information looks like:
> ---
> ERROR 13:37:04,650 [ExecuteThread: '5' for queue: 'default']
> [torry_] (HibernateSpringContractDAO.java:235) -
> org.springframework.jdbc.UncategorizedSQLException:
> executing PreparedStatementCallback: encountered SQLException
> [The transaction is no longer active (status = Rolled back.
> [Reason=weblogic.transaction.internal.TimedOutException:
> Transaction timed out after 29 seconds
> Xid=4954:766e8eae3c8bdd4d(496219),
> Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
> since begin=29,
> seconds left=30,activeThread=Thread[ExecuteThread: '5' for queue:
> 'default',5,
> Thread Group for Queue:
> 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=
>
> (state=started,assigned=none),SCInfo[myappserver+appserver]=(state=act
> ive),
>
>
> properties=({weblogic.jdbc=t3://192.168.1.1:80}),OwnerTransactionManag
> er=ServerTM[ServerCoordinatorDescriptor=
>
> (CoordinatorURL=appserver+192.168.1.1:80+myappserver+,
> Resources={})],
> CoordinatorURL=appserver+192.168.1.1:80+myappserver+)]).
> No further JDBC access is allowed within this transaction.];
> nested exception is java.sql.SQLException: The transaction is no
> longer active
> (status = Rolled back.
> [Reason=weblogic.transaction.internal.TimedOutException:
> Transaction timed out after 29 seconds
> Xid=4954:766e8eae3c8bdd4d(496219),Status=Active,
> numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since
> begin=29,seconds left=30,
> activeThread=Thread[ExecuteThread: '5' for queue:
> 'default',5,Thread Group for Queue: 'default'],
>
> ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=started,assign
> ed=none),
>
>
> SCInfo[myappserver+appserver]=(state=active),properties=({weblogic.jdb
> c=t3://192.168.1.1:80}),
>
>
> OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(Coordina
> torURL=appserver+192.168.1.1:80+myappserver+,
> Resources={})],
> CoordinatorURL=appserver+192.168.1.1:80+myappserver+)]).
> No further JDBC access is allowed within this transaction.
> ---
> The nested exception is:
> ---
> ERROR 13:37:04,650 [ExecuteThread: '5' for queue: 'default']
> [torry_] (ServletUtils.java:221) - Error [trimmed verbose timeout info
> referencing Xid=4954:766e8eae3c8bdd4d(496219)]
> at
> HibernateSpringContractDAO.findContract(HibernateSpringContractDAO.jav
> a:236)
>
> at java.lang.reflect.Method.invoke(Native Method)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflectio
> n(AopUtils.java:288)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoi
> npoint(ReflectiveMethodInvocation.java:155)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(R
> eflectiveMethodInvocation.java:122)
>
> at
> org.springframework.orm.hibernate.HibernateInterceptor.invoke(Hibernat
> eInterceptor.java:164)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(R
> eflectiveMethodInvocation.java:144)
>
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamic
> AopProxy.java:174)
>
> at $Proxy93.findContract(Unknown Source)
> at ContractServiceImpl.findContract(ContractServiceImpl.java:59)
> at java.lang.reflect.Method.invoke(Native Method)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflectio
> n(AopUtils.java:288)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoi
> npoint(ReflectiveMethodInvocation.java:155)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(R
> eflectiveMethodInvocation.java:122)
>
> at
> org.springframework.transaction.interceptor.TransactionInterceptor.inv
> oke(TransactionInterceptor.java:57)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(R
> eflectiveMethodInvocation.java:144)
>
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamic
> AopProxy.java:174)
>
> at $Proxy114.findContract(Unknown Source)
> at AdvanceView.load(AdvanceView.java:228)
> at AdvanceView.process(AdvanceView.java:141)
> at
> jsp_servlet._jsp._advance.__advanceview._jspService(__advanceview.java
> :139)
>
> at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImp
> l.java:275)
>
> at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.jav
> a:27)
>
> at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
> at AccessControlFilter.doFilter(AccessControlFilter.java:79)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.jav
> a:27)
>
> at
> weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatc
> herImpl.java:289)
>
> at
> webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:222)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImp
> l.java:275)
>
> at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.jav
> a:27)
>
> at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
> at AccessControlFilter.doFilter(AccessControlFilter.java:79)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.jav
> a:27)
>
> at
> weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppSer
> vletContext.java:2708)
>
> at
> weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImp
> l.java:2427)
>
> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:159)
> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:140)
> Caused by:
> [trimmed verbose timeout info referencing
> Xid=4954:766e8eae3c8bdd4d(496219)]
> at weblogic.jdbc.jts.Connection.checkIfRolledBack(Connection.java:526)
> at weblogic.jdbc.jts.Connection.prepareStatement(Connection.java:122)
> at
> org.springframework.jdbc.core.JdbcTemplate$SimplePreparedStatementCrea
> tor.createPreparedStatement(JdbcTemplate.java:992)
>
> at
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:444)
> at
> org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:491)
> at
> org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:530)
> at
> org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:548)
> at
> org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:553)
> at
> HibernateSpringContractDAO.findActiveNSF(HibernateSpringContractDAO.ja
> va:716)
>
> at
> HibernateSpringContractDAO.findContract(HibernateSpringContractDAO.jav
> a:231)
>
> ---
> Please let me know what additional information I can provide.
>
> Thanks again for your help,
> Dave
>
> Juergen Hoeller wrote:
>
>> Hi Dave,
>>
>> That's indeed odd, in particular as Spring does not explicitly
>> associate JTA transactions with the current thread (of course the JTA
>> provider itself will use ThreadLocals underneath).
>>
>> The only thing that could be bound to the thread by Spring within a
>> JTA transaction is a transactional resource, such as a JDBC
>> Connection or a Hibernate Session. Such resources should _always_ get
>> removed from the thread by Spring's corresponding synchronization
>> classes, though: So if such a resource would be the root cause, this
>> would mean some bug in Spring's resource cleanup code.
>>
>> If you can track down any details, I'm gonna address this immediately
>> (even during the weekend). It would be great to clarify this before
>> the upcoming Spring 1.2.2 release...
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On
>> Behalf Of Dave Ballard
>> Sent: Friday, June 17, 2005 7:06 PM
>> To: spr...@li...
>> Subject: [Springframework-developer] Stale JTA transaction still
>> attached to a tread
>>
>>
>> Hi Juergen,
>>
>> Using Spring 1.2.1 with JtaTransactionManager with WebLogic 6.1. A
>> review of my logs showed a large number of JTA timeouts. The odd
>> thing is that the timeouts seem all to be occurring on the same
>> thread. What WebLogic reports as the transaction ID is always the same.
>>
>> It appears to me that there is stale Spring JTA transaction attached
>> to this particular thread. Each time WebLogic releases this thread to
>> a request, and attempts to run some SQL (via Spring), it gets a JTA
>> timeout with the same transaction ID.
>>
>> I'm about to restart our server, and I expect this to clear up the
>> problem. However, this is a pretty serious problem. I am going to go
>> back through the logs and attempt to locate the root error for this
>> thread.
>>
>> Thanks for your help,
>> Dave
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration
>> Strategies from IBM. Find simple to follow Roadmaps, straightforward
>> articles, informative Webcasts and more! Get everything you need to
>> get up to speed, fast.
>> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-develope
>> r
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration
>> Strategies from IBM. Find simple to follow Roadmaps, straightforward
>> articles, informative Webcasts and more! Get everything you need to
>> get up to speed, fast.
>> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-develope
>> r
>>
>>
>>
>>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from
IBM. Find simple to follow Roadmaps, straightforward articles, informative
Webcasts and more! Get everything you need to get up to speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Dave B. <dba...@on...> - 2005-06-24 16:47:01
|
Hi Juergen,
Any thoughts on this? It hasn't happened again since I reported it.
Dave
Dave Ballard wrote:
> Hi Juergen,
>
> There was a failure involving the Spring transactional cleanup code
> which may be of interest.
>
> Background: My application architecture is in transition from
> stateless session beans (for transaction demarcation) and entity
> beans, to Spring managed services (and transaction demarcation) and
> dao's. So currently, I've got a mix of both. In some cases, I've got a
> session bean starting a transaction, then that session bean calling a
> Spring service (resulting in the JTA transaction being joined). In
> other newer code, Spring starts the transaction.
>
> The thread in question is ExecuteThread: '5'. The first sign of
> trouble with this thread is a failure of an insert statement. I've
> seen this 'PreparedStatement' exception once before a number of months
> ago. I don't *think* this is a Hibernate bug, as the last time the
> error involved an entity bean. It may be a problem with my JDBC driver.
>
> Spring didn't start this transaction, but at this point in processing,
> SessionFactoryUtils.getSession(sessionFactory, true) has been called
> from the session bean, and a Spring managed service (with a
> JtaTransactionManager transaction interceptor) has also been called.
>
> ---
> ERROR 13:34:55,789 [ExecuteThread: '5' for queue: 'default'] [mariew_]
> (MoneyTransactionSessionEJB.java:459) - Error creating advance
> net.sf.hibernate.JDBCException: could not insert:
> [LedgerEntryClass#LEN000061465159]
> at
> net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java:478)
>
> at
> net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java:442)
>
> at
> net.sf.hibernate.impl.ScheduledInsertion.execute(ScheduledInsertion.java:29)
>
> at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2414)
> at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2367)
> at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2236)
> at
> MoneyTransactionSessionEJB.createLedgerEntriesForNewContractItems(MoneyTransactionSessionEJB.java:5661)
>
> at
> MoneyTransactionSessionEJB.processTransactionInternal(MoneyTransactionSessionEJB.java:704)
>
> at
> MoneyTransactionSessionEJB.processTransaction(MoneyTransactionSessionEJB.java:454)
>
> at
> MoneyTransactionSessionEJB_xvjdlx_ELOImpl.processTransaction(MoneyTransactionSessionEJB_xvjdlx_ELOImpl.java:1037)
>
> at java.lang.reflect.Method.invoke(Native Method)
> at
> org.springframework.ejb.access.LocalSlsbInvokerInterceptor.invoke(LocalSlsbInvokerInterceptor.java:66)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
>
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174)
>
> at $Proxy126.processTransaction(Unknown Source)
> at AdvanceCreate.execute(AdvanceCreate.java:109)
> at AdvanceCommit.createAdvance(AdvanceCommit.java:368)
> at AdvanceCommit.process(AdvanceCommit.java:118)
> at
> jsp_servlet._jsp._advance.__advance_confirm._jspService(__advance_confirm.java:125)
>
> at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:275)
>
> at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
>
> at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
> at AccessControlFilter.doFilter(AccessControlFilter.java:79)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
>
> at
> weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2708)
>
> at
> weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2427)
>
> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:159)
> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:140)
> Caused by:
> java.sql.SQLException: [JTurbo 3.1d9 JDBC 2.1 Driver]:
> PreparedStatement is closed
> at com.newatlanta.jturbo.driver.u.executeUpdate(u.java)
> at weblogic.jdbc.jts.Statement.executeUpdate(Statement.java:508)
> at
> net.sf.hibernate.impl.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:22)
>
> at
> net.sf.hibernate.persister.EntityPersister.insert(EntityPersister.java:468)
>
> ... 29 more
> ---
>
> One minute later, this same thread was used for a different request
> (the username is different):
>
> ---
> ERROR 13:35:56,805 [ExecuteThread: '5' for queue: 'default'] [dan101_]
> (AbstractPlatformTransactionManager.java:585) - Rollback exception
> overridden by synchronization exception
> java.lang.IllegalStateException: No value for key
> [net.sf.hibernate.impl.SessionFactoryImpl@55f3ea] bound to thread
> [ExecuteThread: '5' for queue: 'default']
> at
> org.springframework.transaction.support.TransactionSynchronizationManager.unbindResource(TransactionSynchronizationManager.java:175)
>
> at
> org.springframework.orm.hibernate.SessionFactoryUtils$SpringSessionSynchronization.beforeCompletion(SessionFactoryUtils.java:871)
>
> at
> org.springframework.transaction.support.AbstractPlatformTransactionManager.triggerBeforeCompletion(AbstractPlatformTransactionManager.java:580)
>
> at
> org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:425)
>
> at
> org.springframework.transaction.interceptor.TransactionAspectSupport.doCommitTransactionAfterReturning(TransactionAspectSupport.java:258)
>
> at
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:67)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
>
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174)
>
> at $Proxy114.findContract(Unknown Source)
> at AdvanceView.load(AdvanceView.java:228)
> at AdvanceView.process(AdvanceView.java:141)
> at
> jsp_servlet._jsp._advance.__advanceview._jspService(__advanceview.java:139)
>
> at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:275)
>
> at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
>
> at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
> at AccessControlFilter.doFilter(AccessControlFilter.java:79)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
>
> at
> weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:289)
>
> at
> webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:222)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:275)
>
> at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
>
> at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
> at AccessControlFilter.doFilter(AccessControlFilter.java:79)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
>
> at
> weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:289)
>
> at
> weblogic.servlet.jsp.PageContextImpl.forward(PageContextImpl.java:119)
> at
> jsp_servlet._jsp._advance.__advance_confirm._jspService(__advance_confirm.java:165)
>
> at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:275)
>
> at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
>
> at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
> at AccessControlFilter.doFilter(AccessControlFilter.java:79)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
>
> at
> weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2708)
>
> at
> weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2427)
>
> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:159)
> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:140)
> ---
> There are no nested exceptions. In the previous stack trace, the
> presentation layer called a Spring managed service (which started its
> own transaction).
> After this point, each time ExecuteThread: '5' is used, it fails
> with a org.springframework.jdbc.UncategorizedSQLException wrapping a
> WebLogic TimedOutException. The transaction ID (496219) is always the
> same. This happens over and over again. As I was investigating this
> problem, I began to ask myself "why are all of these timeouts on the
> same thread?". Restarting the app server corrected the problem. The
> timeout information looks like:
> ---
> ERROR 13:37:04,650 [ExecuteThread: '5' for queue: 'default']
> [torry_] (HibernateSpringContractDAO.java:235) -
> org.springframework.jdbc.UncategorizedSQLException:
> executing PreparedStatementCallback: encountered SQLException
> [The transaction is no longer active (status = Rolled back.
> [Reason=weblogic.transaction.internal.TimedOutException:
> Transaction timed out after 29 seconds
> Xid=4954:766e8eae3c8bdd4d(496219),
> Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
> since begin=29,
> seconds left=30,activeThread=Thread[ExecuteThread: '5' for queue:
> 'default',5,
> Thread Group for Queue:
> 'default'],ServerResourceInfo[weblogic.jdbc.jts.Connection]=
>
> (state=started,assigned=none),SCInfo[myappserver+appserver]=(state=active),
>
>
> properties=({weblogic.jdbc=t3://192.168.1.1:80}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=
>
> (CoordinatorURL=appserver+192.168.1.1:80+myappserver+,
> Resources={})],
> CoordinatorURL=appserver+192.168.1.1:80+myappserver+)]).
> No further JDBC access is allowed within this transaction.];
> nested exception is java.sql.SQLException: The transaction is no
> longer active
> (status = Rolled back.
> [Reason=weblogic.transaction.internal.TimedOutException:
> Transaction timed out after 29 seconds
> Xid=4954:766e8eae3c8bdd4d(496219),Status=Active,
> numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since
> begin=29,seconds left=30,
> activeThread=Thread[ExecuteThread: '5' for queue:
> 'default',5,Thread Group for Queue: 'default'],
>
> ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=started,assigned=none),
>
>
> SCInfo[myappserver+appserver]=(state=active),properties=({weblogic.jdbc=t3://192.168.1.1:80}),
>
>
> OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=appserver+192.168.1.1:80+myappserver+,
> Resources={})],
> CoordinatorURL=appserver+192.168.1.1:80+myappserver+)]).
> No further JDBC access is allowed within this transaction.
> ---
> The nested exception is:
> ---
> ERROR 13:37:04,650 [ExecuteThread: '5' for queue: 'default']
> [torry_] (ServletUtils.java:221) - Error
> [trimmed verbose timeout info referencing
> Xid=4954:766e8eae3c8bdd4d(496219)]
> at
> HibernateSpringContractDAO.findContract(HibernateSpringContractDAO.java:236)
>
> at java.lang.reflect.Method.invoke(Native Method)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:288)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:155)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:122)
>
> at
> org.springframework.orm.hibernate.HibernateInterceptor.invoke(HibernateInterceptor.java:164)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
>
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174)
>
> at $Proxy93.findContract(Unknown Source)
> at ContractServiceImpl.findContract(ContractServiceImpl.java:59)
> at java.lang.reflect.Method.invoke(Native Method)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:288)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:155)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:122)
>
> at
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:57)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
>
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174)
>
> at $Proxy114.findContract(Unknown Source)
> at AdvanceView.load(AdvanceView.java:228)
> at AdvanceView.process(AdvanceView.java:141)
> at
> jsp_servlet._jsp._advance.__advanceview._jspService(__advanceview.java:139)
>
> at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:275)
>
> at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
>
> at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
> at AccessControlFilter.doFilter(AccessControlFilter.java:79)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
>
> at
> weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:289)
>
> at
> webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:222)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:275)
>
> at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:21)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
>
> at AccessControlFilter.doFilterInternal(AccessControlFilter.java:186)
> at AccessControlFilter.doFilter(AccessControlFilter.java:79)
> at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
>
> at
> weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2708)
>
> at
> weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2427)
>
> at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:159)
> at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:140)
> Caused by:
> [trimmed verbose timeout info referencing
> Xid=4954:766e8eae3c8bdd4d(496219)]
> at weblogic.jdbc.jts.Connection.checkIfRolledBack(Connection.java:526)
> at weblogic.jdbc.jts.Connection.prepareStatement(Connection.java:122)
> at
> org.springframework.jdbc.core.JdbcTemplate$SimplePreparedStatementCreator.createPreparedStatement(JdbcTemplate.java:992)
>
> at
> org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:444)
> at
> org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:491)
> at
> org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:530)
> at
> org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:548)
> at
> org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:553)
> at
> HibernateSpringContractDAO.findActiveNSF(HibernateSpringContractDAO.java:716)
>
> at
> HibernateSpringContractDAO.findContract(HibernateSpringContractDAO.java:231)
>
> ---
> Please let me know what additional information I can provide.
>
> Thanks again for your help,
> Dave
>
> Juergen Hoeller wrote:
>
>> Hi Dave,
>>
>> That's indeed odd, in particular as Spring does not explicitly
>> associate JTA
>> transactions with the current thread (of course the JTA provider
>> itself will
>> use ThreadLocals underneath).
>>
>> The only thing that could be bound to the thread by Spring within a JTA
>> transaction is a transactional resource, such as a JDBC Connection or a
>> Hibernate Session. Such resources should _always_ get removed from the
>> thread by Spring's corresponding synchronization classes, though: So
>> if such
>> a resource would be the root cause, this would mean some bug in Spring's
>> resource cleanup code.
>>
>> If you can track down any details, I'm gonna address this immediately
>> (even
>> during the weekend). It would be great to clarify this before the
>> upcoming
>> Spring 1.2.2 release...
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On Behalf
>> Of Dave Ballard
>> Sent: Friday, June 17, 2005 7:06 PM
>> To: spr...@li...
>> Subject: [Springframework-developer] Stale JTA transaction still
>> attached to a tread
>>
>>
>> Hi Juergen,
>>
>> Using Spring 1.2.1 with JtaTransactionManager with WebLogic 6.1. A
>> review of my logs showed a large number of JTA timeouts. The odd thing
>> is that the timeouts seem all to be occurring on the same thread. What
>> WebLogic reports as the transaction ID is always the same.
>>
>> It appears to me that there is stale Spring JTA transaction attached to
>> this particular thread. Each time WebLogic releases this thread to a
>> request, and attempts to run some SQL (via Spring), it gets a JTA
>> timeout with the same transaction ID.
>>
>> I'm about to restart our server, and I expect this to clear up the
>> problem. However, this is a pretty serious problem. I am going to go
>> back through the logs and attempt to locate the root error for this
>> thread.
>>
>> Thanks for your help,
>> Dave
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
|
|
From: Andy D. <an...@ma...> - 2005-06-24 15:42:03
|
Wow, this is great response time! This has become quite an issue for us, and it looks like this should solve the issue nicely. Thanks, Andy On Friday 24 June 2005 08:26 am, Juergen Hoeller wrote: > Indeed, in case of an existing JTA transaction, we should try to register > with the JTA TransactionManager and at least synchronize the > "afterCompletion" callback (which receives a transaction status - committed > or rolled back) with the outer transaction. > > I've just reworked AbstractPlatformTransactionManager and > JtaTransactionManager accordingly, registering a corresponding JTA > Synchronization if the JTA TransactionManager is available. Else, it will > still call "afterCompletion" immediately at completion of the Spring > transaction demarcation, but pass in "STATUS_UNKNOWN" now, as we > effectively don't know whether the outer JTA transaction is gonna commit or > roll back. > > This will be shipped in Spring 1.2.2, to be released tonight. > > Juergen |
|
From: Juergen H. <ju...@in...> - 2005-06-24 15:26:33
|
Indeed, in case of an existing JTA transaction, we should try to register with the JTA TransactionManager and at least synchronize the "afterCompletion" callback (which receives a transaction status - committed or rolled back) with the outer transaction. I've just reworked AbstractPlatformTransactionManager and JtaTransactionManager accordingly, registering a corresponding JTA Synchronization if the JTA TransactionManager is available. Else, it will still call "afterCompletion" immediately at completion of the Spring transaction demarcation, but pass in "STATUS_UNKNOWN" now, as we effectively don't know whether the outer JTA transaction is gonna commit or roll back. This will be shipped in Spring 1.2.2, to be released tonight. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Andy Depue Sent: Friday, June 24, 2005 3:06 AM To: spr...@li... Subject: [Springframework-developer] TransactionSynchronization invoked even when participating in existing transaction I've discovered that Spring's PlatformTransactionManager (JTA version in my case) will *always* invoke TransactionSynchronizations when its commit() method is called, even if it is participating in a pre-existing JTA transaction. Is this expected behavior? PlatformTransactionManager's JavaDoc for its "commit" method says, "If the transaction wasn't a new one, omit the commit for proper participation in the surrounding transaction." Which AbstractPlatformTransactionManager does indeed honor - however, it will still call any Spring TransactionSynchronizations against the transaction, as if a commit had been performed anyway. In my case, 3rd party code has started a JTA transaction (not using Spring) and then invoked my Spring based code. My Spring based code relies entirely on Spring for transaction management, and I use TransactionInterceptor around my business interfaces. TranactionInterceptor invokes PlatformTransactionManager, which joins in the already existing JTA transaction (things are going well so far). My code then registers a TransactionSynchronization, assuming that when "afterCompletion" is called on the synchronization that the transaction has been safely committed. However, once my business method exits, TransactionInterceptor will call commit() on PlatformTransactionManager which behaves well and does *not* tell JTA to commit since it had joined an already existing transaction. However, afterCompletion *is* called at this point on my TransactionSynchronization, causing my code to update an external resource as if the transaction is safely committed. However, the actual JTA transaction is still outstanding. What happens in my case is that sometimes the transaction will be rolled back by the 3rd party code, and not only is my TransactionSynchronization never notified, but it also already committed (now invalid) information to an external resource. Based on the description of TransactionSynchronization in Spring, it would seem like a safe assumption that the methods contained therein should track the actual transaction and not just Spring's participation in that transaction. Is this not true? - Andy ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |