springframework-developer — Spring Framework developers list

[Springframework-developer] Removing cyclic dependencies in sub-packages

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

On the occasion of a hint in our current TSS thread, I've run a cyclic =
dependency analysis on our current codebase, using JDepend.

There are two minor cycles in the AOP framework:

- The main one affects AopConfigException, which resides in =
aop.framework but is used in the aop.IntroductionAdvisor interface and =
DefaultIntroductionAdvisor implementation, for the validateInterfaces =
method. I've simply used IllegalArgumentException there, which is =
consistent with other initialization checks within Spring; this has =
removed the AopConfigException cycle.

- The other one affects AopUtils, which resides in aop.framework.support =
but is used outside aop.framework, causing a cyclic dependency. As =
AopUtils is clearly an internal class, not for direct use by =
applications, I've moved it to aop.support; this removes the AopUtils =
cycle too.

The only remaining cycle is DispatcherServlet's instantiation of a =
default ViewResolver, default HandlerMapping, etc: This causes a cycle =
between web.servlet and web.servlet.view/i18n/etc. However, I consider =
this acceptable, as it is just about fallback defaults. We could remove =
this by referring to the default implementation classes by name, but =
that feels odd.

Strictly speaking, the AopUtils move is not backward-compatible, but I'm =
not keen on keeping a deprecated class in the old place. As we're =
talking about an internal class here, I guess this won't break any =
existing application. This raises the following issue: What exactly =
constitutes our public API? We will occasionally face the need to revise =
internals, even for point releases...

Thoughts? Objections?

Juergen



DI J=FCrgen H=F6ller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG

Re: [Springframework-developer] Download problems

[<rod...@in...>]

Now I get this error (same from all mirrors I've tried):

IWSS Security Event (if215)
There is a violation of administrative setting or malicious 
content found in 
http://twtelecom.dl.sourceforge.net/sourceforge/springframewor
k/spring-framework-1.0-with-dependencies.zip. The affected 
file was deleted.
Security warning Exceed_File_Count_Limit in file spring-
framework-1.0-with-dependencies.zip.The non-cleanable file is 
deleted.

Re: [Springframework-developer] Download problems

[Christophe V. <c.v...@pa...>]

On Monday 29 March 2004 11:59, rod...@in... wrote:
> I can't download from any mirror.
>
> Is anyone else having problems? Should we report to SF?
>
> I did successfully download another project this morning, so
> this may just be a problem with the Spring download. Of
> course it was valid when Juergen uploaded it.
>
> Or it may be a problem at my client location...can someone
> please try?
>
> Regards,
> Rod

It must be a SF problem, the download page only shows up with a great delay 
here.
But I was able to download it using the Belnet mirror (which is located in my 
country).

Here's the direct link, maybe it will work for you.
http://belnet.dl.sourceforge.net/sourceforge/springframework/spring-framework-1.0-with-dependencies.zip


-- 
Kind regards,
Christophe Vanfleteren

[Springframework-developer] Download problems

[<rod...@in...>]

I can't download from any mirror. 

Is anyone else having problems? Should we report to SF?

I did successfully download another project this morning, so 
this may just be a problem with the Spring download. Of 
course it was valid when Juergen uploaded it.

Or it may be a problem at my client location...can someone 
please try?

Regards,
Rod

[Springframework-developer] Spring on FreeMarker page (FYI)

[Darren D. <da...@da...>]

http://www.freemarker.org/poweredBy.html

--=20
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp

Re: [Springframework-developer] I think I have found a bug in BeanNameAutoProxyCreator

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

Cameron,

Send me your stuff, I'll have a look at it. I'd like to address all such =
issues for the upcoming 1.0.1, so feel free to report any further ones =
:-)

Juergen


-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...]On Behalf =
Of Cameron Braid
Sent: Monday, March 29, 2004 10:04 AM
To: spr...@li...
Subject: [Springframework-developer] I think I have found a bug in =
BeanNameAutoProxyCreator


I am using a BeanNameAutoProxyCreator to wrap my service beans in a =
security and a transaction interceptor.
=20
I have run into a situation where a bean, that is named in the beanNames =
property, isn't getting proxied.
=20
I am not receiving any exceptions.
=20
The BeanNameAutoProxyCreator loggs messages like=20
=20
[17:58:26]INFO [BeanNameAutoProxyCreator] Creating implicit proxy for =
bean 'authenticationService' with 2 common interceptors and 0 specific =
interceptors
=20
For all beans in the beanNames property, except two beans.
=20
The only thing that is special about these two beans is that they are =
depended on by another bean.
=20
If I remove this dependency (which will cause NullPointerExceptions when =
running my app), all of my service beans get proxied correctly.
=20
There are no ERROR messages, and no stack traces to report.
=20
If someone can help, I can send my applicationContext.xml and log output =
directly, since I don't want to share it with the world ;)
=20
Cheers,
=20
Cameron

[Springframework-developer] I think I have found a bug in BeanNameAutoProxyCreator

[Cameron B. <ca...@da...>]

I am using a BeanNameAutoProxyCreator to wrap my service beans in a security
and a transaction interceptor.

 

I have run into a situation where a bean, that is named in the beanNames
property, isn't getting proxied.

 

I am not receiving any exceptions.

 

The BeanNameAutoProxyCreator loggs messages like 

 

[17:58:26]INFO [BeanNameAutoProxyCreator] Creating implicit proxy for bean
'authenticationService' with 2 common interceptors and 0 specific
interceptors

 

For all beans in the beanNames property, except two beans.

 

The only thing that is special about these two beans is that they are
depended on by another bean.

 

If I remove this dependency (which will cause NullPointerExceptions when
running my app), all of my service beans get proxied correctly.

 

There are no ERROR messages, and no stack traces to report.

 

If someone can help, I can send my applicationContext.xml and log output
directly, since I don't want to share it with the world ;)

 

Cheers,

 

Cameron

Re: [Springframework-developer] Commons-Validator

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

Daniel,
=20
I'm looking forward to giving this a try! For the time being, I suggest =
to add it to the sandbox - Keith, can you do this, as you're dealing =
with declarative validation support? Modifying Petclinic is fine from my =
point of view: It would be ideal to make this configurable, just like =
Hibernate/JDBC data access. As long as the Commons Validator code is not =
in the main src tree, the Petclinic classes should stay in the sandbox =
too, though.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Daniel Miller
Gesendet: Mo 29.03.2004 05:28
An: Springframework-Developer@Lists. Sourceforge. Net
Betreff: [Springframework-developer] Commons-Validator



Now that Spring 1.0 has been released, the necessary changes have been =
made
to MessageResourceResolvable and my commons-validator adaptor for Spring =
is
finally working. I also added a taglib for JavaScript validation.

To provide some examples of how to make it work, I have modified the
Petclinic app to use the commons-validator. Does anyone have any =
objections
to this integration? Would people rather see another dedicated sample =
app
just for the commons-validator example?

Could someone tell me how I could contribute my sources to the Spring
framework?

Thanks,
Daniel



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Commons-Validator

[Daniel M. <mi...@pa...>]

Now that Spring 1.0 has been released, the necessary changes have been made
to MessageResourceResolvable and my commons-validator adaptor for Spring is
finally working. I also added a taglib for JavaScript validation.

To provide some examples of how to make it work, I have modified the
Petclinic app to use the commons-validator. Does anyone have any objections
to this integration? Would people rather see another dedicated sample app
just for the commons-validator example?

Could someone tell me how I could contribute my sources to the Spring
framework?

Thanks,
Daniel

Re: [Springframework-developer] Bug in ChildBeanDefinition

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

Good point - I've just a corresponding check, avoiding a =
StackOverflowError, simply overriding the parent bean with the child =
bean in that case.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Hagen Overdick
Gesendet: So 28.03.2004 09:49
An: spr...@li...
Betreff: [Springframework-developer] Bug in ChildBeanDefinition



Hi,


defining a ChildBean with the same name as its parent will cause a
StackOverFlow. This should be possible in a hierarchical BeanFactory,
where the parent is one up.


Cheers

)-(agen



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Bug in ChildBeanDefinition

[Hagen O. <hag...@hp...>]

Hi,


defining a ChildBean with the same name as its parent will cause a 
StackOverFlow. This should be possible in a hierarchical BeanFactory, 
where the parent is one up.


Cheers

)-(agen

Re: [Springframework-developer] OT: Hibernate resource management issue

[Matthew E. P. <ma...@me...>]

FYI: For those attending TSS Symposium, this book is one of the free 
book choices.


Cheers,
   mattthew

On Mar 27, 2004, at 11:06 AM, Rod Johnson wrote:

> It's not a book about Spring, but a book about J2EE architecture in 
> which
> all examples use Spring and which covers most of the important Spring
> functionality.
>
> Essential reading for Spring developers, or anyone interested in 
> simpler,
> better J2EE architecture.
>
> ----- Original Message -----
> From: "James Cook" <jim...@do...>
> To: <spr...@li...>
> Sent: Saturday, March 27, 2004 3:03 PM
> Subject: RE: [Springframework-developer] OT: Hibernate resource 
> management
> issue
>
>
>> Rod, Juergen,
>>
>> Despite the title's hinting, does this book fully explore the Spring
>> Framework?
>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> [mailto:spr...@li...] On 
>>> Behalf
>>> Of Rod Johnson
>>> Sent: Friday, March 26, 2004 5:21 PM
>>> To: spr...@li...
>>> Subject: Re: [Springframework-developer] OT: Hibernate resource
> management
>>> issue
>>>
>>> http://www.amazon.com/exec/obidos/ASIN/0764558315/
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] OT: Hibernate resource management issue

[Rod J. <rod...@in...>]

It's not a book about Spring, but a book about J2EE architecture in which
all examples use Spring and which covers most of the important Spring
functionality.

Essential reading for Spring developers, or anyone interested in simpler,
better J2EE architecture.

----- Original Message -----
From: "James Cook" <jim...@do...>
To: <spr...@li...>
Sent: Saturday, March 27, 2004 3:03 PM
Subject: RE: [Springframework-developer] OT: Hibernate resource management
issue


> Rod, Juergen,
>
> Despite the title's hinting, does this book fully explore the Spring
> Framework?
>
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On Behalf
> > Of Rod Johnson
> > Sent: Friday, March 26, 2004 5:21 PM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] OT: Hibernate resource
management
> > issue
> >
> > http://www.amazon.com/exec/obidos/ASIN/0764558315/
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

RE: [Springframework-developer] OT: Hibernate resource management issue

[James C. <jim...@do...>]

Rod, Juergen,

Despite the title's hinting, does this book fully explore the Spring
Framework?

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Rod Johnson
> Sent: Friday, March 26, 2004 5:21 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] OT: Hibernate resource management
> issue
> 
> http://www.amazon.com/exec/obidos/ASIN/0764558315/

[Springframework-developer] Hierarchical ApplicationContexts

[Hagen O. <hag...@hp...>]

Me again,


what is the best solution to create hierarchical ApplicataionContexts, 
where the child is a component of the parent?

  For now, I am using ApplicationContextAware. Is there a better way? 
Does the BeanFactory/ApplicationContext have a magic name to reference 
itself?


Cheers

)-(agen

[Springframework-developer] Bug in AbstractApplicationContext

[Hagen O. <hag...@hp...>]

Hi all,


there is a glitch in AbstractApplicationContext.

AbstractBeanFactory.getMergedBeanDefinition() does a "instanceof 
AbstractAutowireCapableBeanFactory"

AbstractApplicationContext does not extend that class, thus autowiring 
is broken, when getParent() is used to initialize the inner 
BeanFactory. The best solution is probably to clean the oo-design...

As a quick work around, I am using:

AbstractApplicationContext {
     public BeanFactory getParentBeanFactory() {
         BeanFactory theParent = getParent();
         if (theParent != null
                 && theParent instanceof ConfigurableApplicationContext) 
{
             theParent = ((ConfigurableApplicationContext) theParent)
                     .getBeanFactory();
         }
         return theParent;
     }
}

and using that method only to initialize the inner BeanFactory.


Cheers

)-(agen

Re: [Springframework-developer] Hibernate resource management issue

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

I considered such wrapping of logging calls too, but I'm not sure =
whether to add it: The downside is that it clutters up the exception =
handling code. (AbstractPlatformTransactionManager has a quite elaborate =
try-try-catch-catch-catch-catch-finally block.)
=20
This sort of problem can just occur when the exception class messes up =
in getMessage or printStackTrace: Normally, this should not occur by any =
means. It certainly won't occur with J2SE 1.4 exception nesting, and it =
won't occur with the adapted version of our nested exception base =
classes.
=20
In our particular case, the deserialization mechanism of the remoting =
protocol was the cause: Nested exception base classes need to be =
programmed defensively here. Still adding try-catch blocks around =
logging statements might be overkill, although I don't have a strong =
opinion on this.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Fr 26.03.2004 23:19
An: spr...@li...
Betreff: Re: [Springframework-developer] Hibernate resource management =
issue



We should probably wrap all logging calls in critical sections (like
catch blocks) in the tx and thread resource mgmt code with empty
try/catch blocks, to avoid this sort of thing in the future.


j=FCrgen h=F6ller [werk3AT] wrote:

>The bug was pretty obscure: It was caused by an exception that came =
across the wire via Hessian. (We had to track down that scenario first.) =
The exception was a custom subclass of Spring's NestedRuntimeException. =
For whatever reason, Hessian put a reference to the exception itself =
into the "cause" instance variable. (This situation cannot occur through =
normal usage of NestedRuntimeException, as it just allows to specify the =
cause in a constructor.) This caused NestedRuntimeException's getMessage =
and printStackTrace to recurse indefinitely, resulting in a =
StackOverflowError. As this was happening in logging code within a catch =
block of TransactionInterceptor, rollback was never invoked, thus no =
cleanup of the associated transactional resources.
>
>A candidate for the most obscure bug in quite a while...
>
>Juergen
>
>
>________________________________
>
>Von: spr...@li... im Auftrag =
von Colin Sampaleanu
>Gesendet: Fr 26.03.2004 16:00
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Hibernate resource management =
issue
>
>
>
>Well, I've never seen a case of the VM not calling catch and finally
>blocks, so for the 2nd problem you have, so my feeling is that it's
>almost certainly got to be a code issue, i.e. the code as written does
>not to do exactly what you think it does...   Could there be another
>catch Throwable somewhere catching even the Error before it gets up to
>that layer?
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
>=20
>
>>triggerAfterCompletion is now called by doRollbackOnCommitException =
(that the catch blocks delegate to), with the correct completion status. =
I've just added catch blocks for RuntimeException and Error there, =
calling triggerAfterCompletion too - although a rollback should never =
throw an exception other than TransactionException, so that's just to be =
on the safe side.
>>
>>Coincidentally, we're just debugging a ThreadLocal problem at werk3AT, =
but with HibernateTransactionManager: In case of some =
StackOverflowErrors thrown by data access operations, the catch/finally =
blocks of our transaction management do not get called (though they =
catch Error), thus the Hibernate Session stays attached to the thread. =
I'm not sure if I understand this: Even in case of an Error, catch and =
finally blocks should get called by the VM... We're currently trying to =
reproduce this, as it just occurs on some machines and just in special =
scenarios.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: Colin Sampaleanu [mailto:col...@ex...]
>>Sent: Friday, March 26, 2004 1:54 PM
>>To: spr...@li...; j=FCrgen h=F6ller
>>[werk3AT]
>>Subject: Re: [Springframework-developer] Hibernate resource management
>>issue
>>
>>
>>I see you also changed the behaviour so that on a RuntimeException or
>>Error, triggerAfterCompletion does not get called any longer, whereas =
it
>>did with the previous code. I am not 100% sure why this went away,
>>considering it was there before, and it is still being done for
>>UnexpectedRollbackException and TransactionException.  (However, I'm =
not
>>100% clear on the semantics of triggerAfterCompletion and whether it
>>always has to be called, I presume it does).
>>
>>
>>j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>
>>
>>  =20
>>
>>>I see - if flush fails, the Session is closed (if no =
TransactionManagerLookup) but not removed from the thread. I've already =
fixed the issue; will commit it promptly. Of course, none of this =
affects HibernateTransactionManager (which is assumably the primary =
choice for Spring apps), but it's still a nasty issue.
>>>
>>>Bad timing - one day earlier, and we would simply have delayed 1.0 =
final for this. I agree that we should do a quick 1.0.1 followup: I've =
also incorporated more sophisticated FieldError message resolution, as =
suggested recently, and will also look at the reported auto-proxy =
creator issue with multiple afterPropertiesSet calls.
>>>
>>>All things considered, I suggest 1.0.1 mid next week. Let's also =
incorporate all reported documentation inconsistencies and the like.
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>>Gesendet: Do 25.03.2004 21:36
>>>An: j=FCrgen h=F6ller [werk3AT]
>>>Cc: spr...@li...
>>>Betreff: Re: [Springframework-developer] Hibernate resource =
management issue
>>>
>>>
>>>
>>>Things are simpler than they appear, and are actually as per my =
original
>>>email. Look at this, from SessionFactoryUtils:
>>>      public void beforeCompletion() throws
>>>CleanupFailureDataAccessException {
>>>          if (this.newSession) {
>>>          =20
>>>TransactionSynchronizationManager.unbindResource(this.sessionFactory);=

>>>              if (this.hibernateTransactionCompletion) {
>>>              =20
>>>closeSessionIfNecessary(this.sessionHolder.getSession(),
>>>this.sessionFactory);
>>>              }
>>>          }
>>>      }
>>>
>>>      public void afterCompletion(int status) {
>>>          if (!this.hibernateTransactionCompletion) {
>>>              Session session =3D this.sessionHolder.getSession();
>>>              if (session instanceof SessionImplementor) {
>>>                  ((SessionImplementor)
>>>session).afterTransactionCompletion(status =3D=3D STATUS_COMMITTED);
>>>              }
>>>              if (this.newSession) {
>>>                  closeSessionIfNecessary(session, =
this.sessionFactory);
>>>              }
>>>          }
>>>          this.sessionHolder.setSynchronizedWithTransaction(false);
>>>      }
>>>
>>>beforeCompletion is the only place that
>>>TransactionSynchronizationManager.unbindResource
>>>gets called for the SessionHolder, and in this case, beforeCompletion
>>>never gets called.
>>>
>>>So unfortunately this _is_ a serious bug. Any exception during the
>>>beforeCommit call (which calls flush) means that the SessionHolder =
never
>>>gets unbound from the thread. Nasty!
>>>
>>>Colin
>>>
>>>
>>>j=FCrgen h=F6ller [werk3AT] wrote:
>>>
>>>
>>>
>>>=20
>>>
>>>    =20
>>>
>>>>Odd - if there's no TransactionManagerLookup, the Session should =
definitely be closed in afterCompletion.
>>>>
>>>>Regarding beforeCompletion, the semantics indeed need to be =
clarified: I guess it's appropriate to always invoke it, even on =
beforeCommit failure.
>>>>
>>>>Juergen
>>>>
>>>>
>>>>________________________________
>>>>
>>>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>>>Gesendet: Do 25.03.2004 21:09
>>>>An: j=FCrgen h=F6ller [werk3AT]
>>>>Cc: spr...@li...
>>>>Betreff: Re: [Springframework-developer] Hibernate resource =
management issue
>>>>
>>>>
>>>>
>>>>We're on slightly different pages though. In my case, I am actually =
not
>>>>using TransactionManagerLookup... But in my case, because of the
>>>>exception in the flush in beforeCommit(), beforeCompletion() never =
gets
>>>>called (as it would normally). Now I do see that afterCompletion is =
also
>>>>supposed to call closeSessionIfNecessary()  (I had actually missed =
this
>>>>before), but in my case, it's not getting there. I haven't traced it =
in
>>>>a debugger, which is what I will do now, as it seems to me it should =
get
>>>>to that code, certainly I do have a
>>>>"Triggering afterCompletion synchronization"
>>>>in the log which should happen right before afterCompletion() is =
called.
>>>>
>>>>The other question is whether beforeCompletion still shouldn't be =
called
>>>>in any case even if beforeCommit fails. Ultimately, we are still =
before
>>>>completion of the transaction, unless you meant it to be only called =
in
>>>>the case of no failure.
>>>>
>>>>Colin
>>>>
>>>>
>>>>j=FCrgen h=F6ller [werk3AT] wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  =20
>>>>
>>>>      =20
>>>>
>>>>>Colin,
>>>>>
>>>>>Thanks for tracking this down. It's actually a problem with =
SessionFactoryUtils' inner class SessionSynchronization: It assumes that =
beforeCompletion is called in any case, even if beforeCommit has thrown =
an exception. However, this just applies if you specified a =
TransactionManagerLookup in the Hibernate configuration; else, =
afterCompletion will do the cleanup - which will be called in any case.
>>>>>
>>>>>When you remove the Hibernate TransactionManagerLookup, you =
shouldn't face the issue - the bug doesn't have any effects then. Note =
that you don't need that TransactionManagerLookup when using Spring's =
JtaTransactionManager, as Spring will properly apply cache callbacks =
anyway. A TransactionManagerLookup just adds value when used with EJB =
CMT or manual JTA, for ultra-correct cache callbacks.
>>>>>
>>>>>So essentially, everything should be fine if using =
HibernateTransactionManager, or JtaTransactionManager without a =
Hibernate TransactionManagerLookup. This is clearly something to fix, =
but I guess we don't need to do an immediate 1.0.1 followup release; I'd =
like to gather further bug reports first. For the time being, let's =
suggest to remove the TransactionManagerLookup from the Hibernate =
configuration.
>>>>>
>>>>>Juergen
>>>>>
>>>>>
>>>>>________________________________
>>>>>
>>>>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>>>>Gesendet: Do 25.03.2004 20:32
>>>>>An: spr...@li...; j=FCrgen =
h=F6ller [werk3AT]
>>>>>Betreff: Re: [Springframework-developer] Hibernate resource =
management issue
>>>>>
>>>>>
>>>>>
>>>>>Juergen,
>>>>>
>>>>>I am almost 100% sure this block of code from
>>>>>AbstractPlatformTransactionManager is wrong:
>>>>>    else {
>>>>>        try {
>>>>>            try {
>>>>>                triggerBeforeCommit(defStatus);
>>>>>                triggerBeforeCompletion(defStatus);
>>>>>                if (status.isNewTransaction()) {
>>>>>                    logger.info("Initiating transaction commit");
>>>>>                    doCommit(defStatus);
>>>>>                }
>>>>>            }
>>>>>            catch (UnexpectedRollbackException ex) {
>>>>>                triggerAfterCompletion(defStatus,
>>>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>>>                throw ex;
>>>>>            }
>>>>>            catch (TransactionException ex) {
>>>>>                if (this.rollbackOnCommitFailure) {
>>>>>                    doRollbackOnCommitException(defStatus, ex);
>>>>>                    triggerAfterCompletion(defStatus,
>>>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>>>                }
>>>>>                else {
>>>>>                    triggerAfterCompletion(defStatus,
>>>>>TransactionSynchronization.STATUS_UNKNOWN, ex);
>>>>>                }
>>>>>                throw ex;
>>>>>            }
>>>>>            catch (RuntimeException ex) {
>>>>>                doRollbackOnCommitException(defStatus, ex);
>>>>>                triggerAfterCompletion(defStatus,
>>>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>>>                throw ex;
>>>>>            }
>>>>>            catch (Error err) {
>>>>>                doRollbackOnCommitException(defStatus, err);
>>>>>                triggerAfterCompletion(defStatus,
>>>>>TransactionSynchronization.STATUS_UNKNOWN, err);
>>>>>                throw err;
>>>>>            }
>>>>>            triggerAfterCompletion(defStatus,
>>>>>TransactionSynchronization.STATUS_COMMITTED, null);
>>>>>        }
>>>>>        finally {
>>>>>            cleanupAfterCompletion(defStatus);
>>>>>        }
>>>>>    }
>>>>>
>>>>>triggerBeforeCommit() execute, which in the Hibernate case will =
force a
>>>>>flush. However, if that flush throws an exception, then
>>>>>triggerBeforeCompletion(defStatus);
>>>>>never gets called. However, triggerBeforeCompletion is what is =
actually
>>>>>supposed to release the Hibernate session holder from the current
>>>>>thread! So in this case, the session (which is totally hosed of =
course),
>>>>>gets left on the thread. I believe in some environments this =
wouldn't
>>>>>matter that much, as the threads don't get resused. In the JBoss =
case,
>>>>>new requests coming in will get the existing thread, and this time,
>>>>>SessionFactoryUtils will see the session is there, and try to use =
it.
>>>>>Bang, it all blows up...
>>>>>
>>>>>So for this code to work properly, what needs to happen is that
>>>>>triggerBeforeCompletion still needs to be called even if
>>>>>triggerBeforeCommit fails. While I am ok with writing the code in =
this
>>>>>method to handle this, I am not 100% sure this is safe in terms of =
all
>>>>>the other interactions that will happen as a result; mot of this =
code is
>>>>>your baby with me only having traced through it once in a while. So =
if
>>>>>you would prefer to resolve this that would be great.
>>>>>
>>>>>Unless I am mistaken about this bug, I think it is a pretty serious =
one,
>>>>>and warrants an almost immediate release of a v1.0.1 of Spring...
>>>>>
>>>>>Regards,
>>>>>Colin
>>>>>
>>>>>
>>>>>Colin Sampaleanu wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> =20
>>>>>
>>>>>    =20
>>>>>
>>>>>        =20
>>>>>
>>>>>>I am tracking down a possible Hibernate resource management issue.
>>>>>>
>>>>>>In a running app, some time yesterday, some code, running in a =
wrapped
>>>>>>transaction with Hibernate handling ORM, encountered an Oracle
>>>>>>constraint violation and threw an exception. Fine...
>>>>>>
>>>>>>But when I log into the app myself now via the web ui and then it =
gets
>>>>>>a service object to read some data, the service object is wrapped =
with
>>>>>>a transaction interceptor, and also a hibernate interceptor. The
>>>>>>Hibernate interceptor is already seeing a Hibernate Session =
existing
>>>>>>on the current thread, so it is not creating a new one. Then at =
the
>>>>>>end of the transaction, when the Hibernate session is attempted to =
be
>>>>>>flushed, Hibernate tries to write out the old bad data from =
yesterday.
>>>>>>
>>>>>>What this essentially means is that when the error from yesterday
>>>>>>happened, the session did not get released from the thread, and =
has
>>>>>>been sticking around all this time. When I came via struts, I was
>>>>>>given the same thread as yesterday by the appserver, and the old
>>>>>>invalid session was still on it. The problem is not that it's =
reusing
>>>>>>that session, but why it was ever left that the day before.
>>>>>>
>>>>>>Will try to duplicate this...
>>>>>>          =20
>>>>>>



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] OT: Hibernate resource management issue

[Rod J. <rod...@in...>]

http://www.amazon.com/exec/obidos/ASIN/0764558315/

----- Original Message -----
From: "Ronald Haring" <ro...@co...>
To: <spr...@li...>
Sent: Friday, March 26, 2004 10:11 PM
Subject: Re: [Springframework-developer] OT: Hibernate resource managemen=
t
issue


> Wow,
>
> while you are busy doing search marvelous research Juergen, could you
> try and find out who really killed JFK?   :)
>
> Obscure bug award +1
>
> On a side note, I saw some mentions to a new book that you are writing?
> Is this correct and if so, where is it pre-ordable? I can handle a bit
> of spring now, but you keep amazing me with your knowledge of every
> little obscure detail of the inner workings of spring, and I wouldnt
> mind to read about this.
>
> Cheers
> Ronald
>
>
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
> >The bug was pretty obscure: It was caused by an exception that came
across the wire via Hessian. (We had to track down that scenario first.) =
The
exception was a custom subclass of Spring's NestedRuntimeException. For
whatever reason, Hessian put a reference to the exception itself into the
"cause" instance variable. (This situation cannot occur through normal us=
age
of NestedRuntimeException, as it just allows to specify the cause in a
constructor.) This caused NestedRuntimeException's getMessage and
printStackTrace to recurse indefinitely, resulting in a StackOverflowErro=
r.
As this was happening in logging code within a catch block of
TransactionInterceptor, rollback was never invoked, thus no cleanup of th=
e
associated transactional resources.
> >
> >A candidate for the most obscure bug in quite a while...
> >
> >Juergen
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Hibernate resource management issue

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

We should probably wrap all logging calls in critical sections (like=20
catch blocks) in the tx and thread resource mgmt code with empty=20
try/catch blocks, to avoid this sort of thing in the future.


j=FCrgen h=F6ller [werk3AT] wrote:

>The bug was pretty obscure: It was caused by an exception that came acro=
ss the wire via Hessian. (We had to track down that scenario first.) The =
exception was a custom subclass of Spring's NestedRuntimeException. For w=
hatever reason, Hessian put a reference to the exception itself into the =
"cause" instance variable. (This situation cannot occur through normal us=
age of NestedRuntimeException, as it just allows to specify the cause in =
a constructor.) This caused NestedRuntimeException's getMessage and print=
StackTrace to recurse indefinitely, resulting in a StackOverflowError. As=
 this was happening in logging code within a catch block of TransactionIn=
terceptor, rollback was never invoked, thus no cleanup of the associated =
transactional resources.
>=20
>A candidate for the most obscure bug in quite a while...
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n Colin Sampaleanu
>Gesendet: Fr 26.03.2004 16:00
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Hibernate resource management i=
ssue
>
>
>
>Well, I've never seen a case of the VM not calling catch and finally
>blocks, so for the 2nd problem you have, so my feeling is that it's
>almost certainly got to be a code issue, i.e. the code as written does
>not to do exactly what you think it does...   Could there be another
>catch Throwable somewhere catching even the Error before it gets up to
>that layer?
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
> =20
>
>>triggerAfterCompletion is now called by doRollbackOnCommitException (th=
at the catch blocks delegate to), with the correct completion status. I'v=
e just added catch blocks for RuntimeException and Error there, calling t=
riggerAfterCompletion too - although a rollback should never throw an exc=
eption other than TransactionException, so that's just to be on the safe =
side.
>>
>>Coincidentally, we're just debugging a ThreadLocal problem at werk3AT, =
but with HibernateTransactionManager: In case of some StackOverflowErrors=
 thrown by data access operations, the catch/finally blocks of our transa=
ction management do not get called (though they catch Error), thus the Hi=
bernate Session stays attached to the thread. I'm not sure if I understan=
d this: Even in case of an Error, catch and finally blocks should get cal=
led by the VM... We're currently trying to reproduce this, as it just occ=
urs on some machines and just in special scenarios.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: Colin Sampaleanu [mailto:col...@ex...]
>>Sent: Friday, March 26, 2004 1:54 PM
>>To: spr...@li...; j=FCrgen h=F6ller
>>[werk3AT]
>>Subject: Re: [Springframework-developer] Hibernate resource management
>>issue
>>
>>
>>I see you also changed the behaviour so that on a RuntimeException or
>>Error, triggerAfterCompletion does not get called any longer, whereas i=
t
>>did with the previous code. I am not 100% sure why this went away,
>>considering it was there before, and it is still being done for
>>UnexpectedRollbackException and TransactionException.  (However, I'm no=
t
>>100% clear on the semantics of triggerAfterCompletion and whether it
>>always has to be called, I presume it does).
>>
>>
>>j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>
>>
>>   =20
>>
>>>I see - if flush fails, the Session is closed (if no TransactionManage=
rLookup) but not removed from the thread. I've already fixed the issue; w=
ill commit it promptly. Of course, none of this affects HibernateTransact=
ionManager (which is assumably the primary choice for Spring apps), but i=
t's still a nasty issue.
>>>
>>>Bad timing - one day earlier, and we would simply have delayed 1.0 fin=
al for this. I agree that we should do a quick 1.0.1 followup: I've also =
incorporated more sophisticated FieldError message resolution, as suggest=
ed recently, and will also look at the reported auto-proxy creator issue =
with multiple afterPropertiesSet calls.
>>>
>>>All things considered, I suggest 1.0.1 mid next week. Let's also incor=
porate all reported documentation inconsistencies and the like.
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>>Gesendet: Do 25.03.2004 21:36
>>>An: j=FCrgen h=F6ller [werk3AT]
>>>Cc: spr...@li...
>>>Betreff: Re: [Springframework-developer] Hibernate resource management=
 issue
>>>
>>>
>>>
>>>Things are simpler than they appear, and are actually as per my origin=
al
>>>email. Look at this, from SessionFactoryUtils:
>>>      public void beforeCompletion() throws
>>>CleanupFailureDataAccessException {
>>>          if (this.newSession) {
>>>           =20
>>>TransactionSynchronizationManager.unbindResource(this.sessionFactory);
>>>              if (this.hibernateTransactionCompletion) {
>>>               =20
>>>closeSessionIfNecessary(this.sessionHolder.getSession(),
>>>this.sessionFactory);
>>>              }
>>>          }
>>>      }
>>>
>>>      public void afterCompletion(int status) {
>>>          if (!this.hibernateTransactionCompletion) {
>>>              Session session =3D this.sessionHolder.getSession();
>>>              if (session instanceof SessionImplementor) {
>>>                  ((SessionImplementor)
>>>session).afterTransactionCompletion(status =3D=3D STATUS_COMMITTED);
>>>              }
>>>              if (this.newSession) {
>>>                  closeSessionIfNecessary(session, this.sessionFactory=
);
>>>              }
>>>          }
>>>          this.sessionHolder.setSynchronizedWithTransaction(false);
>>>      }
>>>
>>>beforeCompletion is the only place that
>>>TransactionSynchronizationManager.unbindResource
>>>gets called for the SessionHolder, and in this case, beforeCompletion
>>>never gets called.
>>>
>>>So unfortunately this _is_ a serious bug. Any exception during the
>>>beforeCommit call (which calls flush) means that the SessionHolder nev=
er
>>>gets unbound from the thread. Nasty!
>>>
>>>Colin
>>>
>>>
>>>j=FCrgen h=F6ller [werk3AT] wrote:
>>>
>>>
>>>
>>> =20
>>>
>>>     =20
>>>
>>>>Odd - if there's no TransactionManagerLookup, the Session should defi=
nitely be closed in afterCompletion.
>>>>
>>>>Regarding beforeCompletion, the semantics indeed need to be clarified=
: I guess it's appropriate to always invoke it, even on beforeCommit fail=
ure.
>>>>
>>>>Juergen
>>>>
>>>>
>>>>________________________________
>>>>
>>>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>>>Gesendet: Do 25.03.2004 21:09
>>>>An: j=FCrgen h=F6ller [werk3AT]
>>>>Cc: spr...@li...
>>>>Betreff: Re: [Springframework-developer] Hibernate resource managemen=
t issue
>>>>
>>>>
>>>>
>>>>We're on slightly different pages though. In my case, I am actually n=
ot
>>>>using TransactionManagerLookup... But in my case, because of the
>>>>exception in the flush in beforeCommit(), beforeCompletion() never ge=
ts
>>>>called (as it would normally). Now I do see that afterCompletion is a=
lso
>>>>supposed to call closeSessionIfNecessary()  (I had actually missed th=
is
>>>>before), but in my case, it's not getting there. I haven't traced it =
in
>>>>a debugger, which is what I will do now, as it seems to me it should =
get
>>>>to that code, certainly I do have a
>>>>"Triggering afterCompletion synchronization"
>>>>in the log which should happen right before afterCompletion() is call=
ed.
>>>>
>>>>The other question is whether beforeCompletion still shouldn't be cal=
led
>>>>in any case even if beforeCommit fails. Ultimately, we are still befo=
re
>>>>completion of the transaction, unless you meant it to be only called =
in
>>>>the case of no failure.
>>>>
>>>>Colin
>>>>
>>>>
>>>>j=FCrgen h=F6ller [werk3AT] wrote:
>>>>
>>>>
>>>>
>>>>=20
>>>>
>>>>   =20
>>>>
>>>>       =20
>>>>
>>>>>Colin,
>>>>>
>>>>>Thanks for tracking this down. It's actually a problem with SessionF=
actoryUtils' inner class SessionSynchronization: It assumes that beforeCo=
mpletion is called in any case, even if beforeCommit has thrown an except=
ion. However, this just applies if you specified a TransactionManagerLook=
up in the Hibernate configuration; else, afterCompletion will do the clea=
nup - which will be called in any case.
>>>>>
>>>>>When you remove the Hibernate TransactionManagerLookup, you shouldn'=
t face the issue - the bug doesn't have any effects then. Note that you d=
on't need that TransactionManagerLookup when using Spring's JtaTransactio=
nManager, as Spring will properly apply cache callbacks anyway. A Transac=
tionManagerLookup just adds value when used with EJB CMT or manual JTA, f=
or ultra-correct cache callbacks.
>>>>>
>>>>>So essentially, everything should be fine if using HibernateTransact=
ionManager, or JtaTransactionManager without a Hibernate TransactionManag=
erLookup. This is clearly something to fix, but I guess we don't need to =
do an immediate 1.0.1 followup release; I'd like to gather further bug re=
ports first. For the time being, let's suggest to remove the TransactionM=
anagerLookup from the Hibernate configuration.
>>>>>
>>>>>Juergen
>>>>>
>>>>>
>>>>>________________________________
>>>>>
>>>>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>>>>Gesendet: Do 25.03.2004 20:32
>>>>>An: spr...@li...; j=FCrgen h=F6ll=
er [werk3AT]
>>>>>Betreff: Re: [Springframework-developer] Hibernate resource manageme=
nt issue
>>>>>
>>>>>
>>>>>
>>>>>Juergen,
>>>>>
>>>>>I am almost 100% sure this block of code from
>>>>>AbstractPlatformTransactionManager is wrong:
>>>>>    else {
>>>>>        try {
>>>>>            try {
>>>>>                triggerBeforeCommit(defStatus);
>>>>>                triggerBeforeCompletion(defStatus);
>>>>>                if (status.isNewTransaction()) {
>>>>>                    logger.info("Initiating transaction commit");
>>>>>                    doCommit(defStatus);
>>>>>                }
>>>>>            }
>>>>>            catch (UnexpectedRollbackException ex) {
>>>>>                triggerAfterCompletion(defStatus,
>>>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>>>                throw ex;
>>>>>            }
>>>>>            catch (TransactionException ex) {
>>>>>                if (this.rollbackOnCommitFailure) {
>>>>>                    doRollbackOnCommitException(defStatus, ex);
>>>>>                    triggerAfterCompletion(defStatus,
>>>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>>>                }
>>>>>                else {
>>>>>                    triggerAfterCompletion(defStatus,
>>>>>TransactionSynchronization.STATUS_UNKNOWN, ex);
>>>>>                }
>>>>>                throw ex;
>>>>>            }
>>>>>            catch (RuntimeException ex) {
>>>>>                doRollbackOnCommitException(defStatus, ex);
>>>>>                triggerAfterCompletion(defStatus,
>>>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>>>                throw ex;
>>>>>            }
>>>>>            catch (Error err) {
>>>>>                doRollbackOnCommitException(defStatus, err);
>>>>>                triggerAfterCompletion(defStatus,
>>>>>TransactionSynchronization.STATUS_UNKNOWN, err);
>>>>>                throw err;
>>>>>            }
>>>>>            triggerAfterCompletion(defStatus,
>>>>>TransactionSynchronization.STATUS_COMMITTED, null);
>>>>>        }
>>>>>        finally {
>>>>>            cleanupAfterCompletion(defStatus);
>>>>>        }
>>>>>    }
>>>>>
>>>>>triggerBeforeCommit() execute, which in the Hibernate case will forc=
e a
>>>>>flush. However, if that flush throws an exception, then
>>>>>triggerBeforeCompletion(defStatus);
>>>>>never gets called. However, triggerBeforeCompletion is what is actua=
lly
>>>>>supposed to release the Hibernate session holder from the current
>>>>>thread! So in this case, the session (which is totally hosed of cour=
se),
>>>>>gets left on the thread. I believe in some environments this wouldn'=
t
>>>>>matter that much, as the threads don't get resused. In the JBoss cas=
e,
>>>>>new requests coming in will get the existing thread, and this time,
>>>>>SessionFactoryUtils will see the session is there, and try to use it=
.
>>>>>Bang, it all blows up...
>>>>>
>>>>>So for this code to work properly, what needs to happen is that
>>>>>triggerBeforeCompletion still needs to be called even if
>>>>>triggerBeforeCommit fails. While I am ok with writing the code in th=
is
>>>>>method to handle this, I am not 100% sure this is safe in terms of a=
ll
>>>>>the other interactions that will happen as a result; mot of this cod=
e is
>>>>>your baby with me only having traced through it once in a while. So =
if
>>>>>you would prefer to resolve this that would be great.
>>>>>
>>>>>Unless I am mistaken about this bug, I think it is a pretty serious =
one,
>>>>>and warrants an almost immediate release of a v1.0.1 of Spring...
>>>>>
>>>>>Regards,
>>>>>Colin
>>>>>
>>>>>
>>>>>Colin Sampaleanu wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  =20
>>>>>
>>>>>     =20
>>>>>
>>>>>         =20
>>>>>
>>>>>>I am tracking down a possible Hibernate resource management issue.
>>>>>>
>>>>>>In a running app, some time yesterday, some code, running in a wrap=
ped
>>>>>>transaction with Hibernate handling ORM, encountered an Oracle
>>>>>>constraint violation and threw an exception. Fine...
>>>>>>
>>>>>>But when I log into the app myself now via the web ui and then it g=
ets
>>>>>>a service object to read some data, the service object is wrapped w=
ith
>>>>>>a transaction interceptor, and also a hibernate interceptor. The
>>>>>>Hibernate interceptor is already seeing a Hibernate Session existin=
g
>>>>>>on the current thread, so it is not creating a new one. Then at the
>>>>>>end of the transaction, when the Hibernate session is attempted to =
be
>>>>>>flushed, Hibernate tries to write out the old bad data from yesterd=
ay.
>>>>>>
>>>>>>What this essentially means is that when the error from yesterday
>>>>>>happened, the session did not get released from the thread, and has
>>>>>>been sticking around all this time. When I came via struts, I was
>>>>>>given the same thread as yesterday by the appserver, and the old
>>>>>>invalid session was still on it. The problem is not that it's reusi=
ng
>>>>>>that session, but why it was ever left that the day before.
>>>>>>
>>>>>>Will try to duplicate this...
>>>>>>           =20
>>>>>>

Re: [Springframework-developer] OT: Hibernate resource management issue

[Ronald H. <ro...@co...>]

Wow,

while you are busy doing search marvelous research Juergen, could you 
try and find out who really killed JFK?   :)

Obscure bug award +1

On a side note, I saw some mentions to a new book that you are writing? 
Is this correct and if so, where is it pre-ordable? I can handle a bit 
of spring now, but you keep amazing me with your knowledge of every 
little obscure detail of the inner workings of spring, and I wouldnt 
mind to read about this.

Cheers
Ronald



jürgen höller [werk3AT] wrote:

>The bug was pretty obscure: It was caused by an exception that came across the wire via Hessian. (We had to track down that scenario first.) The exception was a custom subclass of Spring's NestedRuntimeException. For whatever reason, Hessian put a reference to the exception itself into the "cause" instance variable. (This situation cannot occur through normal usage of NestedRuntimeException, as it just allows to specify the cause in a constructor.) This caused NestedRuntimeException's getMessage and printStackTrace to recurse indefinitely, resulting in a StackOverflowError. As this was happening in logging code within a catch block of TransactionInterceptor, rollback was never invoked, thus no cleanup of the associated transactional resources.
> 
>A candidate for the most obscure bug in quite a while...
> 
>Juergen
>  
>

Re: [Springframework-developer] Hibernate resource management issue

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

The bug was pretty obscure: It was caused by an exception that came =
across the wire via Hessian. (We had to track down that scenario first.) =
The exception was a custom subclass of Spring's NestedRuntimeException. =
For whatever reason, Hessian put a reference to the exception itself =
into the "cause" instance variable. (This situation cannot occur through =
normal usage of NestedRuntimeException, as it just allows to specify the =
cause in a constructor.) This caused NestedRuntimeException's getMessage =
and printStackTrace to recurse indefinitely, resulting in a =
StackOverflowError. As this was happening in logging code within a catch =
block of TransactionInterceptor, rollback was never invoked, thus no =
cleanup of the associated transactional resources.
=20
A candidate for the most obscure bug in quite a while...
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Fr 26.03.2004 16:00
An: spr...@li...
Betreff: Re: [Springframework-developer] Hibernate resource management =
issue



Well, I've never seen a case of the VM not calling catch and finally
blocks, so for the 2nd problem you have, so my feeling is that it's
almost certainly got to be a code issue, i.e. the code as written does
not to do exactly what you think it does...   Could there be another
catch Throwable somewhere catching even the Error before it gets up to
that layer?

j=FCrgen h=F6ller [werk3AT] wrote:

>triggerAfterCompletion is now called by doRollbackOnCommitException =
(that the catch blocks delegate to), with the correct completion status. =
I've just added catch blocks for RuntimeException and Error there, =
calling triggerAfterCompletion too - although a rollback should never =
throw an exception other than TransactionException, so that's just to be =
on the safe side.
>
>Coincidentally, we're just debugging a ThreadLocal problem at werk3AT, =
but with HibernateTransactionManager: In case of some =
StackOverflowErrors thrown by data access operations, the catch/finally =
blocks of our transaction management do not get called (though they =
catch Error), thus the Hibernate Session stays attached to the thread. =
I'm not sure if I understand this: Even in case of an Error, catch and =
finally blocks should get called by the VM... We're currently trying to =
reproduce this, as it just occurs on some machines and just in special =
scenarios.
>
>Juergen
>
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...]
>Sent: Friday, March 26, 2004 1:54 PM
>To: spr...@li...; j=FCrgen h=F6ller
>[werk3AT]
>Subject: Re: [Springframework-developer] Hibernate resource management
>issue
>
>
>I see you also changed the behaviour so that on a RuntimeException or
>Error, triggerAfterCompletion does not get called any longer, whereas =
it
>did with the previous code. I am not 100% sure why this went away,
>considering it was there before, and it is still being done for
>UnexpectedRollbackException and TransactionException.  (However, I'm =
not
>100% clear on the semantics of triggerAfterCompletion and whether it
>always has to be called, I presume it does).
>
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
>=20
>
>>I see - if flush fails, the Session is closed (if no =
TransactionManagerLookup) but not removed from the thread. I've already =
fixed the issue; will commit it promptly. Of course, none of this =
affects HibernateTransactionManager (which is assumably the primary =
choice for Spring apps), but it's still a nasty issue.
>>
>>Bad timing - one day earlier, and we would simply have delayed 1.0 =
final for this. I agree that we should do a quick 1.0.1 followup: I've =
also incorporated more sophisticated FieldError message resolution, as =
suggested recently, and will also look at the reported auto-proxy =
creator issue with multiple afterPropertiesSet calls.
>>
>>All things considered, I suggest 1.0.1 mid next week. Let's also =
incorporate all reported documentation inconsistencies and the like.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>Gesendet: Do 25.03.2004 21:36
>>An: j=FCrgen h=F6ller [werk3AT]
>>Cc: spr...@li...
>>Betreff: Re: [Springframework-developer] Hibernate resource management =
issue
>>
>>
>>
>>Things are simpler than they appear, and are actually as per my =
original
>>email. Look at this, from SessionFactoryUtils:
>>       public void beforeCompletion() throws
>>CleanupFailureDataAccessException {
>>           if (this.newSession) {
>>            =20
>>TransactionSynchronizationManager.unbindResource(this.sessionFactory);
>>               if (this.hibernateTransactionCompletion) {
>>                =20
>>closeSessionIfNecessary(this.sessionHolder.getSession(),
>>this.sessionFactory);
>>               }
>>           }
>>       }
>>
>>       public void afterCompletion(int status) {
>>           if (!this.hibernateTransactionCompletion) {
>>               Session session =3D this.sessionHolder.getSession();
>>               if (session instanceof SessionImplementor) {
>>                   ((SessionImplementor)
>>session).afterTransactionCompletion(status =3D=3D STATUS_COMMITTED);
>>               }
>>               if (this.newSession) {
>>                   closeSessionIfNecessary(session, =
this.sessionFactory);
>>               }
>>           }
>>           this.sessionHolder.setSynchronizedWithTransaction(false);
>>       }
>>
>>beforeCompletion is the only place that
>> TransactionSynchronizationManager.unbindResource
>>gets called for the SessionHolder, and in this case, beforeCompletion
>>never gets called.
>>
>>So unfortunately this _is_ a serious bug. Any exception during the
>>beforeCommit call (which calls flush) means that the SessionHolder =
never
>>gets unbound from the thread. Nasty!
>>
>>Colin
>>
>>
>>j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>
>>
>>  =20
>>
>>>Odd - if there's no TransactionManagerLookup, the Session should =
definitely be closed in afterCompletion.
>>>
>>>Regarding beforeCompletion, the semantics indeed need to be =
clarified: I guess it's appropriate to always invoke it, even on =
beforeCommit failure.
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>>Gesendet: Do 25.03.2004 21:09
>>>An: j=FCrgen h=F6ller [werk3AT]
>>>Cc: spr...@li...
>>>Betreff: Re: [Springframework-developer] Hibernate resource =
management issue
>>>
>>>
>>>
>>>We're on slightly different pages though. In my case, I am actually =
not
>>>using TransactionManagerLookup... But in my case, because of the
>>>exception in the flush in beforeCommit(), beforeCompletion() never =
gets
>>>called (as it would normally). Now I do see that afterCompletion is =
also
>>>supposed to call closeSessionIfNecessary()  (I had actually missed =
this
>>>before), but in my case, it's not getting there. I haven't traced it =
in
>>>a debugger, which is what I will do now, as it seems to me it should =
get
>>>to that code, certainly I do have a
>>> "Triggering afterCompletion synchronization"
>>>in the log which should happen right before afterCompletion() is =
called.
>>>
>>>The other question is whether beforeCompletion still shouldn't be =
called
>>>in any case even if beforeCommit fails. Ultimately, we are still =
before
>>>completion of the transaction, unless you meant it to be only called =
in
>>>the case of no failure.
>>>
>>>Colin
>>>
>>>
>>>j=FCrgen h=F6ller [werk3AT] wrote:
>>>
>>>
>>>
>>> =20
>>>
>>>    =20
>>>
>>>>Colin,
>>>>
>>>>Thanks for tracking this down. It's actually a problem with =
SessionFactoryUtils' inner class SessionSynchronization: It assumes that =
beforeCompletion is called in any case, even if beforeCommit has thrown =
an exception. However, this just applies if you specified a =
TransactionManagerLookup in the Hibernate configuration; else, =
afterCompletion will do the cleanup - which will be called in any case.
>>>>
>>>>When you remove the Hibernate TransactionManagerLookup, you =
shouldn't face the issue - the bug doesn't have any effects then. Note =
that you don't need that TransactionManagerLookup when using Spring's =
JtaTransactionManager, as Spring will properly apply cache callbacks =
anyway. A TransactionManagerLookup just adds value when used with EJB =
CMT or manual JTA, for ultra-correct cache callbacks.
>>>>
>>>>So essentially, everything should be fine if using =
HibernateTransactionManager, or JtaTransactionManager without a =
Hibernate TransactionManagerLookup. This is clearly something to fix, =
but I guess we don't need to do an immediate 1.0.1 followup release; I'd =
like to gather further bug reports first. For the time being, let's =
suggest to remove the TransactionManagerLookup from the Hibernate =
configuration.
>>>>
>>>>Juergen
>>>>
>>>>
>>>>________________________________
>>>>
>>>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>>>Gesendet: Do 25.03.2004 20:32
>>>>An: spr...@li...; j=FCrgen =
h=F6ller [werk3AT]
>>>>Betreff: Re: [Springframework-developer] Hibernate resource =
management issue
>>>>
>>>>
>>>>
>>>>Juergen,
>>>>
>>>>I am almost 100% sure this block of code from
>>>>AbstractPlatformTransactionManager is wrong:
>>>>     else {
>>>>         try {
>>>>             try {
>>>>                 triggerBeforeCommit(defStatus);
>>>>                 triggerBeforeCompletion(defStatus);
>>>>                 if (status.isNewTransaction()) {
>>>>                     logger.info("Initiating transaction commit");
>>>>                     doCommit(defStatus);
>>>>                 }
>>>>             }
>>>>             catch (UnexpectedRollbackException ex) {
>>>>                 triggerAfterCompletion(defStatus,
>>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>>                 throw ex;
>>>>             }
>>>>             catch (TransactionException ex) {
>>>>                 if (this.rollbackOnCommitFailure) {
>>>>                     doRollbackOnCommitException(defStatus, ex);
>>>>                     triggerAfterCompletion(defStatus,
>>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>>                 }
>>>>                 else {
>>>>                     triggerAfterCompletion(defStatus,
>>>>TransactionSynchronization.STATUS_UNKNOWN, ex);
>>>>                 }
>>>>                 throw ex;
>>>>             }
>>>>             catch (RuntimeException ex) {
>>>>                 doRollbackOnCommitException(defStatus, ex);
>>>>                 triggerAfterCompletion(defStatus,
>>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>>                 throw ex;
>>>>             }
>>>>             catch (Error err) {
>>>>                 doRollbackOnCommitException(defStatus, err);
>>>>                 triggerAfterCompletion(defStatus,
>>>>TransactionSynchronization.STATUS_UNKNOWN, err);
>>>>                 throw err;
>>>>             }
>>>>             triggerAfterCompletion(defStatus,
>>>>TransactionSynchronization.STATUS_COMMITTED, null);
>>>>         }
>>>>         finally {
>>>>             cleanupAfterCompletion(defStatus);
>>>>         }
>>>>     }
>>>>
>>>>triggerBeforeCommit() execute, which in the Hibernate case will =
force a
>>>>flush. However, if that flush throws an exception, then
>>>>triggerBeforeCompletion(defStatus);
>>>>never gets called. However, triggerBeforeCompletion is what is =
actually
>>>>supposed to release the Hibernate session holder from the current
>>>>thread! So in this case, the session (which is totally hosed of =
course),
>>>>gets left on the thread. I believe in some environments this =
wouldn't
>>>>matter that much, as the threads don't get resused. In the JBoss =
case,
>>>>new requests coming in will get the existing thread, and this time,
>>>>SessionFactoryUtils will see the session is there, and try to use =
it.
>>>>Bang, it all blows up...
>>>>
>>>>So for this code to work properly, what needs to happen is that
>>>>triggerBeforeCompletion still needs to be called even if
>>>>triggerBeforeCommit fails. While I am ok with writing the code in =
this
>>>>method to handle this, I am not 100% sure this is safe in terms of =
all
>>>>the other interactions that will happen as a result; mot of this =
code is
>>>>your baby with me only having traced through it once in a while. So =
if
>>>>you would prefer to resolve this that would be great.
>>>>
>>>>Unless I am mistaken about this bug, I think it is a pretty serious =
one,
>>>>and warrants an almost immediate release of a v1.0.1 of Spring...
>>>>
>>>>Regards,
>>>>Colin
>>>>
>>>>
>>>>Colin Sampaleanu wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>   =20
>>>>
>>>>      =20
>>>>
>>>>>I am tracking down a possible Hibernate resource management issue.
>>>>>
>>>>>In a running app, some time yesterday, some code, running in a =
wrapped
>>>>>transaction with Hibernate handling ORM, encountered an Oracle
>>>>>constraint violation and threw an exception. Fine...
>>>>>
>>>>>But when I log into the app myself now via the web ui and then it =
gets
>>>>>a service object to read some data, the service object is wrapped =
with
>>>>>a transaction interceptor, and also a hibernate interceptor. The
>>>>>Hibernate interceptor is already seeing a Hibernate Session =
existing
>>>>>on the current thread, so it is not creating a new one. Then at the
>>>>>end of the transaction, when the Hibernate session is attempted to =
be
>>>>>flushed, Hibernate tries to write out the old bad data from =
yesterday.
>>>>>
>>>>>What this essentially means is that when the error from yesterday
>>>>>happened, the session did not get released from the thread, and has
>>>>>been sticking around all this time. When I came via struts, I was
>>>>>given the same thread as yesterday by the appserver, and the old
>>>>>invalid session was still on it. The problem is not that it's =
reusing
>>>>>that session, but why it was ever left that the day before.
>>>>>
>>>>>Will try to duplicate this...
>>>>>     =20
>>>>>
>>>>>        =20
>>>>>
>
>
>=20
>



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Help for Sring AOP

[wangyz <wa...@1n...>]

aGVsbG8ueW91IGNhbiBzZWUgdGhlIEp1bml0VGVzdCBhYm91dCBzcHJpbmd3b3JrLg0KICAtLS0t
LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBjZyANCiAgVG86IHNwcmluZ2ZyYW1l
d29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KICBTZW50OiBUaHVyc2RheSwg
TWFyY2ggMjUsIDIwMDQgMTE6MDcgUE0NCiAgU3ViamVjdDogW1NwcmluZ2ZyYW1ld29yay1kZXZl
bG9wZXJdIEhlbHAgZm9yIFNyaW5nIEFPUA0KDQoNCiAgSGkhDQogIEkgbWV0IHNvbWUgcHJvYmxl
bSBhYm91dCBTcHJpbmcgQU9QLkkgZG9uJ3Qga25vdyBob3cgdG8gd3JpdGUgcHJvZ3JhbSBhYm91
dCBBT1AuUGxlYXNlIGdpdmUgbWUgc29tZSBleGFtcGxlIGNvZGUgYWJvdXQgU3ByaW5nIEFvcC5U
aGFuayB5b3Uh

Re: [Springframework-developer] New bean instantiation "type"

[Andy D. <an...@ma...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I hate to crosspost, but the conversion in the help forum is progressing, a=
nd=20
I still want to bounce this idea off of the Spring developers.  See the end=
=20
of this message for a possible "solution".

  - Andy

On Thursday 25 March 2004 09:49 am, Andy Depue wrote:
> Hello,
>   I posted a message to the Spring "help" forum, and it has become more of
> a development idea.  I'd like to copy the two help forum messages here and
> solicit feedback from Spring developers.  You will find the two messages
> below.
>   Thanks for your consideration.
>
> First message, posted 3/24/04:
>
> <<<<<<<<<<<<
>
> I have two questions regarding Spring's instantiation of beans that are n=
ot
> singletons.
>  First, let's say I have the following XML:
>
>  ----
>  <beans>
>  <bean id=3D"a" class=3D"A" singleton=3D"false">
>  <property name=3D"b">
>  <ref bean=3D"b"/>
>  </property>
>  </bean>
>
>  <bean id=3D"b" class=3D"B" singleton=3D"false">
>  <property name=3D"c">
>  <ref bean=3D"c"/>
>  </property>
>  </bean>
>
>  <bean id=3D"c" class=3D"C" singleton=3D"false">
>  <property name=3D"a">
>  <ref bean=3D"a"/>
>  </property>
>  </bean>
>  </beans>
>  ----
>
>  What will Spring do when I attempt to get "a"? Will this even work? How
> many times will each class be instantiated?
>  The second question is similar to the first. Here is another config file:
>
>  ----
>  <beans>
>  <bean id=3D"a" class=3D"A" singleton=3D"false">
>  <property name=3D"b">
>  <ref bean=3D"b"/>
>  </property>
>
>  <property name=3D"c">
>  <ref bean=3D"c"/>
>  </property>
>  </bean>
>
>  <bean id=3D"b" class=3D"B" singleton=3D"false">
>  <property name=3D"c">
>  <ref bean=3D"c"/>
>  </property>
>  </bean>
>
>  <bean id=3D"c" class=3D"C" singleton=3D"false">
>  </bean>
>  </beans>
>  ----
>  When I attempt to get "a", how many times will "c" be instantiated? Once
> for each reference, or once for the entire getBean call?
>
> <<<<<<<<<<<<<<<<<<<<<
>
> I then decided to perform my own tests based on the two examples above.=20
> Here is my response:
>
> <<<<<<<<<<<<<<<<<<<<<
>
> Well, I've tested it, and my fears are confirmed. Everytime a non-singlet=
on
> is referenced in the XML, it is re-instantiated. I haven't looked at
> Spring's source code, but I'm guessing it is using getBean internally to
> get a bean referenced in the XML. This means that the first example never
> returns. It is either stuck in an infinite loop, or it is in infinite
> recursion, though after a minute of running I didn't get a StackOverflow.
>  The second example instantiates C twice, though it does return.
>  What I need is the ability to have an object graph instantiated every ti=
me
> getBean is called, though in that instantiation, referenced objects should
> only be instantiated at most one time.
>  Look at the second example. What we would like is the ability to have A,
> B, and C instantiated every time getBean is called, but each class should
> be instantiated at most once. In other words, the same C reference is
> passed to both A and B, though all these objects will be reinstantiated t=
he
> next time getBean is called. The behavior we are looking for would be
> exactly the same as if all the beans were singletons, but we used a new
> XmlBeanFactory for every call of getBean. Of course, this is a possible
> solution to our problem, but I'm guessing it would be terribly ineffecien=
t.
>  Right now there are two "types" of bean instantiation: singleton, and
> non-singleton. Does anyone see value in creating a third type? This new
> type would indicate, "create a new instance of the object for each
> getBean(...) call, but never more than one instance, so that all referenc=
es
> within the scope of the getBean(...) call get the same instance on
> reference."
>

Here is one thought on a solution. First, let's say the two examples above =
use=20
all Singletons. With singletons, the two examples actually work (though you=
=20
won't get a new instance every getBean call), because Spring "eagerly cache=
s"=20
the instances (I'm assuming). In other words, the moment Spring instantiate=
s=20
an instance, it puts it in the cache even before the bean has been fully=20
initialized. It is impossible to get around circular references in=20
constructors (since the beans haven't been cached because they haven't been=
=20
instantiated), but that's OK... I can live with that. In the two examples=20
above, beans are wired with properties (not constructor arguments). So,=20
Spring would instantiate A, put it in the cache, instantiate B, put it in t=
he=20
cache, instantiate C, put it in the cache, then pull the cached instance of=
 A=20
and set the 'a' property on C, and so on.
 With that in mind, consider the option of creating some new kind of=20
"instantiation" type. I don't know, let's say there is a=20
singleton=3D"per-getbean" option (for lack of a better term). How would thi=
s be=20
implemented? Use two levels of "cache", one that is factory wide (as it is=
=20
currently implemented), and one that is "getBean" wide. Regular singletons=
=20
get cached in the factory wide cache, non-singletons don't get cached at al=
l,=20
and "per-getbean" singletons get cached in the "getBean" cache. Obviously,=
=20
you would have to implement this getBean cache as either a cache object tha=
t=20
gets passed around to all the methods that getBean calls, a thread local=20
variable, or some such thing. Whatever the case, getBean would clear its=20
local cache before returning (though it wouldn't dispose of the objects, mu=
ch=20
how non-singletons work).
 This would solve the problem: upon every invocation of getBean, getBean's=
=20
local cache would be empty, thus ensuring that each "per-getbean" singleton=
=20
is instantiated per getBean call, but never more than once in the scope of=
=20
that call. It would also ensure that singletons and non-singletons continue=
=20
to work as they do now. This would not only provide backward compatibility,=
=20
but would also solve the issue that Al brought up: what if you want some to=
=20
be instantiated every reference, and others insantiated only "per getbean"?=
=20
Use singleton=3D"false" for one, and the per-getbean option for the other.
 Thoughts?=20
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAZFZfdgQy3TUmt38RAshFAJ9kj5YkdQ1kn5vNg85xq+F898NBYgCdE3qL
NfYsOsQo3IgKLpngkN2aIXk=3D
=3D43tK
=2D----END PGP SIGNATURE-----

Re: [Springframework-developer] Hibernate resource management issue

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

Well, I've never seen a case of the VM not calling catch and finally=20
blocks, so for the 2nd problem you have, so my feeling is that it's=20
almost certainly got to be a code issue, i.e. the code as written does=20
not to do exactly what you think it does...   Could there be another=20
catch Throwable somewhere catching even the Error before it gets up to=20
that layer?

j=FCrgen h=F6ller [werk3AT] wrote:

>triggerAfterCompletion is now called by doRollbackOnCommitException (tha=
t the catch blocks delegate to), with the correct completion status. I've=
 just added catch blocks for RuntimeException and Error there, calling tr=
iggerAfterCompletion too - although a rollback should never throw an exce=
ption other than TransactionException, so that's just to be on the safe s=
ide.
>
>Coincidentally, we're just debugging a ThreadLocal problem at werk3AT, b=
ut with HibernateTransactionManager: In case of some StackOverflowErrors =
thrown by data access operations, the catch/finally blocks of our transac=
tion management do not get called (though they catch Error), thus the Hib=
ernate Session stays attached to the thread. I'm not sure if I understand=
 this: Even in case of an Error, catch and finally blocks should get call=
ed by the VM... We're currently trying to reproduce this, as it just occu=
rs on some machines and just in special scenarios.
>
>Juergen
>
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:col...@ex...]
>Sent: Friday, March 26, 2004 1:54 PM
>To: spr...@li...; j=FCrgen h=F6ller
>[werk3AT]
>Subject: Re: [Springframework-developer] Hibernate resource management
>issue
>
>
>I see you also changed the behaviour so that on a RuntimeException or=20
>Error, triggerAfterCompletion does not get called any longer, whereas it=
=20
>did with the previous code. I am not 100% sure why this went away,=20
>considering it was there before, and it is still being done for=20
>UnexpectedRollbackException and TransactionException.  (However, I'm not=
=20
>100% clear on the semantics of triggerAfterCompletion and whether it=20
>always has to be called, I presume it does).
>
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
> =20
>
>>I see - if flush fails, the Session is closed (if no TransactionManager=
Lookup) but not removed from the thread. I've already fixed the issue; wi=
ll commit it promptly. Of course, none of this affects HibernateTransacti=
onManager (which is assumably the primary choice for Spring apps), but it=
's still a nasty issue.
>>
>>Bad timing - one day earlier, and we would simply have delayed 1.0 fina=
l for this. I agree that we should do a quick 1.0.1 followup: I've also i=
ncorporated more sophisticated FieldError message resolution, as suggeste=
d recently, and will also look at the reported auto-proxy creator issue w=
ith multiple afterPropertiesSet calls.
>>
>>All things considered, I suggest 1.0.1 mid next week. Let's also incorp=
orate all reported documentation inconsistencies and the like.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>Gesendet: Do 25.03.2004 21:36
>>An: j=FCrgen h=F6ller [werk3AT]
>>Cc: spr...@li...
>>Betreff: Re: [Springframework-developer] Hibernate resource management =
issue
>>
>>
>>
>>Things are simpler than they appear, and are actually as per my origina=
l
>>email. Look at this, from SessionFactoryUtils:
>>       public void beforeCompletion() throws
>>CleanupFailureDataAccessException {
>>           if (this.newSession) {
>>             =20
>>TransactionSynchronizationManager.unbindResource(this.sessionFactory);
>>               if (this.hibernateTransactionCompletion) {
>>                 =20
>>closeSessionIfNecessary(this.sessionHolder.getSession(),
>>this.sessionFactory);
>>               }
>>           }
>>       }
>>
>>       public void afterCompletion(int status) {
>>           if (!this.hibernateTransactionCompletion) {
>>               Session session =3D this.sessionHolder.getSession();
>>               if (session instanceof SessionImplementor) {
>>                   ((SessionImplementor)
>>session).afterTransactionCompletion(status =3D=3D STATUS_COMMITTED);
>>               }
>>               if (this.newSession) {
>>                   closeSessionIfNecessary(session, this.sessionFactory=
);
>>               }
>>           }
>>           this.sessionHolder.setSynchronizedWithTransaction(false);
>>       }
>>
>>beforeCompletion is the only place that
>> TransactionSynchronizationManager.unbindResource
>>gets called for the SessionHolder, and in this case, beforeCompletion
>>never gets called.
>>
>>So unfortunately this _is_ a serious bug. Any exception during the
>>beforeCommit call (which calls flush) means that the SessionHolder neve=
r
>>gets unbound from the thread. Nasty!
>>
>>Colin
>>
>>
>>j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>=20
>>
>>   =20
>>
>>>Odd - if there's no TransactionManagerLookup, the Session should defin=
itely be closed in afterCompletion.
>>>
>>>Regarding beforeCompletion, the semantics indeed need to be clarified:=
 I guess it's appropriate to always invoke it, even on beforeCommit failu=
re.
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>>Gesendet: Do 25.03.2004 21:09
>>>An: j=FCrgen h=F6ller [werk3AT]
>>>Cc: spr...@li...
>>>Betreff: Re: [Springframework-developer] Hibernate resource management=
 issue
>>>
>>>
>>>
>>>We're on slightly different pages though. In my case, I am actually no=
t
>>>using TransactionManagerLookup... But in my case, because of the
>>>exception in the flush in beforeCommit(), beforeCompletion() never get=
s
>>>called (as it would normally). Now I do see that afterCompletion is al=
so
>>>supposed to call closeSessionIfNecessary()  (I had actually missed thi=
s
>>>before), but in my case, it's not getting there. I haven't traced it i=
n
>>>a debugger, which is what I will do now, as it seems to me it should g=
et
>>>to that code, certainly I do have a
>>> "Triggering afterCompletion synchronization"
>>>in the log which should happen right before afterCompletion() is calle=
d.
>>>
>>>The other question is whether beforeCompletion still shouldn't be call=
ed
>>>in any case even if beforeCommit fails. Ultimately, we are still befor=
e
>>>completion of the transaction, unless you meant it to be only called i=
n
>>>the case of no failure.
>>>
>>>Colin
>>>
>>>
>>>j=FCrgen h=F6ller [werk3AT] wrote:
>>>
>>>
>>>
>>>  =20
>>>
>>>     =20
>>>
>>>>Colin,
>>>>
>>>>Thanks for tracking this down. It's actually a problem with SessionFa=
ctoryUtils' inner class SessionSynchronization: It assumes that beforeCom=
pletion is called in any case, even if beforeCommit has thrown an excepti=
on. However, this just applies if you specified a TransactionManagerLooku=
p in the Hibernate configuration; else, afterCompletion will do the clean=
up - which will be called in any case.
>>>>
>>>>When you remove the Hibernate TransactionManagerLookup, you shouldn't=
 face the issue - the bug doesn't have any effects then. Note that you do=
n't need that TransactionManagerLookup when using Spring's JtaTransaction=
Manager, as Spring will properly apply cache callbacks anyway. A Transact=
ionManagerLookup just adds value when used with EJB CMT or manual JTA, fo=
r ultra-correct cache callbacks.
>>>>
>>>>So essentially, everything should be fine if using HibernateTransacti=
onManager, or JtaTransactionManager without a Hibernate TransactionManage=
rLookup. This is clearly something to fix, but I guess we don't need to d=
o an immediate 1.0.1 followup release; I'd like to gather further bug rep=
orts first. For the time being, let's suggest to remove the TransactionMa=
nagerLookup from the Hibernate configuration.
>>>>
>>>>Juergen
>>>>
>>>>
>>>>________________________________
>>>>
>>>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>>>Gesendet: Do 25.03.2004 20:32
>>>>An: spr...@li...; j=FCrgen h=F6lle=
r [werk3AT]
>>>>Betreff: Re: [Springframework-developer] Hibernate resource managemen=
t issue
>>>>
>>>>
>>>>
>>>>Juergen,
>>>>
>>>>I am almost 100% sure this block of code from
>>>>AbstractPlatformTransactionManager is wrong:
>>>>     else {
>>>>         try {
>>>>             try {
>>>>                 triggerBeforeCommit(defStatus);
>>>>                 triggerBeforeCompletion(defStatus);
>>>>                 if (status.isNewTransaction()) {
>>>>                     logger.info("Initiating transaction commit");
>>>>                     doCommit(defStatus);
>>>>                 }
>>>>             }
>>>>             catch (UnexpectedRollbackException ex) {
>>>>                 triggerAfterCompletion(defStatus,
>>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>>                 throw ex;
>>>>             }
>>>>             catch (TransactionException ex) {
>>>>                 if (this.rollbackOnCommitFailure) {
>>>>                     doRollbackOnCommitException(defStatus, ex);
>>>>                     triggerAfterCompletion(defStatus,
>>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>>                 }
>>>>                 else {
>>>>                     triggerAfterCompletion(defStatus,
>>>>TransactionSynchronization.STATUS_UNKNOWN, ex);
>>>>                 }
>>>>                 throw ex;
>>>>             }
>>>>             catch (RuntimeException ex) {
>>>>                 doRollbackOnCommitException(defStatus, ex);
>>>>                 triggerAfterCompletion(defStatus,
>>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>>                 throw ex;
>>>>             }
>>>>             catch (Error err) {
>>>>                 doRollbackOnCommitException(defStatus, err);
>>>>                 triggerAfterCompletion(defStatus,
>>>>TransactionSynchronization.STATUS_UNKNOWN, err);
>>>>                 throw err;
>>>>             }
>>>>             triggerAfterCompletion(defStatus,
>>>>TransactionSynchronization.STATUS_COMMITTED, null);
>>>>         }
>>>>         finally {
>>>>             cleanupAfterCompletion(defStatus);
>>>>         }
>>>>     }
>>>>
>>>>triggerBeforeCommit() execute, which in the Hibernate case will force=
 a
>>>>flush. However, if that flush throws an exception, then
>>>>triggerBeforeCompletion(defStatus);
>>>>never gets called. However, triggerBeforeCompletion is what is actual=
ly
>>>>supposed to release the Hibernate session holder from the current
>>>>thread! So in this case, the session (which is totally hosed of cours=
e),
>>>>gets left on the thread. I believe in some environments this wouldn't
>>>>matter that much, as the threads don't get resused. In the JBoss case=
,
>>>>new requests coming in will get the existing thread, and this time,
>>>>SessionFactoryUtils will see the session is there, and try to use it.
>>>>Bang, it all blows up...
>>>>
>>>>So for this code to work properly, what needs to happen is that
>>>>triggerBeforeCompletion still needs to be called even if
>>>>triggerBeforeCommit fails. While I am ok with writing the code in thi=
s
>>>>method to handle this, I am not 100% sure this is safe in terms of al=
l
>>>>the other interactions that will happen as a result; mot of this code=
 is
>>>>your baby with me only having traced through it once in a while. So i=
f
>>>>you would prefer to resolve this that would be great.
>>>>
>>>>Unless I am mistaken about this bug, I think it is a pretty serious o=
ne,
>>>>and warrants an almost immediate release of a v1.0.1 of Spring...
>>>>
>>>>Regards,
>>>>Colin
>>>>
>>>>
>>>>Colin Sampaleanu wrote:
>>>>
>>>>
>>>>
>>>>=20
>>>>
>>>>    =20
>>>>
>>>>       =20
>>>>
>>>>>I am tracking down a possible Hibernate resource management issue.
>>>>>
>>>>>In a running app, some time yesterday, some code, running in a wrapp=
ed
>>>>>transaction with Hibernate handling ORM, encountered an Oracle
>>>>>constraint violation and threw an exception. Fine...
>>>>>
>>>>>But when I log into the app myself now via the web ui and then it ge=
ts
>>>>>a service object to read some data, the service object is wrapped wi=
th
>>>>>a transaction interceptor, and also a hibernate interceptor. The
>>>>>Hibernate interceptor is already seeing a Hibernate Session existing
>>>>>on the current thread, so it is not creating a new one. Then at the
>>>>>end of the transaction, when the Hibernate session is attempted to b=
e
>>>>>flushed, Hibernate tries to write out the old bad data from yesterda=
y.
>>>>>
>>>>>What this essentially means is that when the error from yesterday
>>>>>happened, the session did not get released from the thread, and has
>>>>>been sticking around all this time. When I came via struts, I was
>>>>>given the same thread as yesterday by the appserver, and the old
>>>>>invalid session was still on it. The problem is not that it's reusin=
g
>>>>>that session, but why it was ever left that the day before.
>>>>>
>>>>>Will try to duplicate this...
>>>>>      =20
>>>>>
>>>>>         =20
>>>>>
>
>
> =20
>

Re: [Springframework-developer] Hibernate resource management issue

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

triggerAfterCompletion is now called by doRollbackOnCommitException =
(that the catch blocks delegate to), with the correct completion status. =
I've just added catch blocks for RuntimeException and Error there, =
calling triggerAfterCompletion too - although a rollback should never =
throw an exception other than TransactionException, so that's just to be =
on the safe side.

Coincidentally, we're just debugging a ThreadLocal problem at werk3AT, =
but with HibernateTransactionManager: In case of some =
StackOverflowErrors thrown by data access operations, the catch/finally =
blocks of our transaction management do not get called (though they =
catch Error), thus the Hibernate Session stays attached to the thread. =
I'm not sure if I understand this: Even in case of an Error, catch and =
finally blocks should get called by the VM... We're currently trying to =
reproduce this, as it just occurs on some machines and just in special =
scenarios.

Juergen


-----Original Message-----
From: Colin Sampaleanu [mailto:col...@ex...]
Sent: Friday, March 26, 2004 1:54 PM
To: spr...@li...; j=FCrgen h=F6ller
[werk3AT]
Subject: Re: [Springframework-developer] Hibernate resource management
issue


I see you also changed the behaviour so that on a RuntimeException or=20
Error, triggerAfterCompletion does not get called any longer, whereas it =

did with the previous code. I am not 100% sure why this went away,=20
considering it was there before, and it is still being done for=20
UnexpectedRollbackException and TransactionException.  (However, I'm not =

100% clear on the semantics of triggerAfterCompletion and whether it=20
always has to be called, I presume it does).


j=FCrgen h=F6ller [werk3AT] wrote:

>I see - if flush fails, the Session is closed (if no =
TransactionManagerLookup) but not removed from the thread. I've already =
fixed the issue; will commit it promptly. Of course, none of this =
affects HibernateTransactionManager (which is assumably the primary =
choice for Spring apps), but it's still a nasty issue.
>=20
>Bad timing - one day earlier, and we would simply have delayed 1.0 =
final for this. I agree that we should do a quick 1.0.1 followup: I've =
also incorporated more sophisticated FieldError message resolution, as =
suggested recently, and will also look at the reported auto-proxy =
creator issue with multiple afterPropertiesSet calls.
>=20
>All things considered, I suggest 1.0.1 mid next week. Let's also =
incorporate all reported documentation inconsistencies and the like.
>=20
>Juergen
>=20
>
>________________________________
>
>Von: Colin Sampaleanu [mailto:col...@ex...]
>Gesendet: Do 25.03.2004 21:36
>An: j=FCrgen h=F6ller [werk3AT]
>Cc: spr...@li...
>Betreff: Re: [Springframework-developer] Hibernate resource management =
issue
>
>
>
>Things are simpler than they appear, and are actually as per my =
original
>email. Look at this, from SessionFactoryUtils:
>        public void beforeCompletion() throws
>CleanupFailureDataAccessException {
>            if (this.newSession) {
>              =20
>TransactionSynchronizationManager.unbindResource(this.sessionFactory);
>                if (this.hibernateTransactionCompletion) {
>                  =20
>closeSessionIfNecessary(this.sessionHolder.getSession(),
>this.sessionFactory);
>                }
>            }
>        }
>
>        public void afterCompletion(int status) {
>            if (!this.hibernateTransactionCompletion) {
>                Session session =3D this.sessionHolder.getSession();
>                if (session instanceof SessionImplementor) {
>                    ((SessionImplementor)
>session).afterTransactionCompletion(status =3D=3D STATUS_COMMITTED);
>                }
>                if (this.newSession) {
>                    closeSessionIfNecessary(session, =
this.sessionFactory);
>                }
>            }
>            this.sessionHolder.setSynchronizedWithTransaction(false);
>        }
>
>beforeCompletion is the only place that
>  TransactionSynchronizationManager.unbindResource
>gets called for the SessionHolder, and in this case, beforeCompletion
>never gets called.
>
>So unfortunately this _is_ a serious bug. Any exception during the
>beforeCommit call (which calls flush) means that the SessionHolder =
never
>gets unbound from the thread. Nasty!
>
>Colin
>
>
>j=FCrgen h=F6ller [werk3AT] wrote:
>
> =20
>
>>Odd - if there's no TransactionManagerLookup, the Session should =
definitely be closed in afterCompletion.
>>
>>Regarding beforeCompletion, the semantics indeed need to be clarified: =
I guess it's appropriate to always invoke it, even on beforeCommit =
failure.
>>
>>Juergen
>>
>>
>>________________________________
>>
>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>Gesendet: Do 25.03.2004 21:09
>>An: j=FCrgen h=F6ller [werk3AT]
>>Cc: spr...@li...
>>Betreff: Re: [Springframework-developer] Hibernate resource management =
issue
>>
>>
>>
>>We're on slightly different pages though. In my case, I am actually =
not
>>using TransactionManagerLookup... But in my case, because of the
>>exception in the flush in beforeCommit(), beforeCompletion() never =
gets
>>called (as it would normally). Now I do see that afterCompletion is =
also
>>supposed to call closeSessionIfNecessary()  (I had actually missed =
this
>>before), but in my case, it's not getting there. I haven't traced it =
in
>>a debugger, which is what I will do now, as it seems to me it should =
get
>>to that code, certainly I do have a
>>  "Triggering afterCompletion synchronization"
>>in the log which should happen right before afterCompletion() is =
called.
>>
>>The other question is whether beforeCompletion still shouldn't be =
called
>>in any case even if beforeCommit fails. Ultimately, we are still =
before
>>completion of the transaction, unless you meant it to be only called =
in
>>the case of no failure.
>>
>>Colin
>>
>>
>>j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>
>>
>>   =20
>>
>>>Colin,
>>>
>>>Thanks for tracking this down. It's actually a problem with =
SessionFactoryUtils' inner class SessionSynchronization: It assumes that =
beforeCompletion is called in any case, even if beforeCommit has thrown =
an exception. However, this just applies if you specified a =
TransactionManagerLookup in the Hibernate configuration; else, =
afterCompletion will do the cleanup - which will be called in any case.
>>>
>>>When you remove the Hibernate TransactionManagerLookup, you shouldn't =
face the issue - the bug doesn't have any effects then. Note that you =
don't need that TransactionManagerLookup when using Spring's =
JtaTransactionManager, as Spring will properly apply cache callbacks =
anyway. A TransactionManagerLookup just adds value when used with EJB =
CMT or manual JTA, for ultra-correct cache callbacks.
>>>
>>>So essentially, everything should be fine if using =
HibernateTransactionManager, or JtaTransactionManager without a =
Hibernate TransactionManagerLookup. This is clearly something to fix, =
but I guess we don't need to do an immediate 1.0.1 followup release; I'd =
like to gather further bug reports first. For the time being, let's =
suggest to remove the TransactionManagerLookup from the Hibernate =
configuration.
>>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: Colin Sampaleanu [mailto:col...@ex...]
>>>Gesendet: Do 25.03.2004 20:32
>>>An: spr...@li...; j=FCrgen =
h=F6ller [werk3AT]
>>>Betreff: Re: [Springframework-developer] Hibernate resource =
management issue
>>>
>>>
>>>
>>>Juergen,
>>>
>>>I am almost 100% sure this block of code from
>>>AbstractPlatformTransactionManager is wrong:
>>>      else {
>>>          try {
>>>              try {
>>>                  triggerBeforeCommit(defStatus);
>>>                  triggerBeforeCompletion(defStatus);
>>>                  if (status.isNewTransaction()) {
>>>                      logger.info("Initiating transaction commit");
>>>                      doCommit(defStatus);
>>>                  }
>>>              }
>>>              catch (UnexpectedRollbackException ex) {
>>>                  triggerAfterCompletion(defStatus,
>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>                  throw ex;
>>>              }
>>>              catch (TransactionException ex) {
>>>                  if (this.rollbackOnCommitFailure) {
>>>                      doRollbackOnCommitException(defStatus, ex);
>>>                      triggerAfterCompletion(defStatus,
>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>                  }
>>>                  else {
>>>                      triggerAfterCompletion(defStatus,
>>>TransactionSynchronization.STATUS_UNKNOWN, ex);
>>>                  }
>>>                  throw ex;
>>>              }
>>>              catch (RuntimeException ex) {
>>>                  doRollbackOnCommitException(defStatus, ex);
>>>                  triggerAfterCompletion(defStatus,
>>>TransactionSynchronization.STATUS_ROLLED_BACK, ex);
>>>                  throw ex;
>>>              }
>>>              catch (Error err) {
>>>                  doRollbackOnCommitException(defStatus, err);
>>>                  triggerAfterCompletion(defStatus,
>>>TransactionSynchronization.STATUS_UNKNOWN, err);
>>>                  throw err;
>>>              }
>>>              triggerAfterCompletion(defStatus,
>>>TransactionSynchronization.STATUS_COMMITTED, null);
>>>          }
>>>          finally {
>>>              cleanupAfterCompletion(defStatus);
>>>          }
>>>      }
>>>
>>>triggerBeforeCommit() execute, which in the Hibernate case will force =
a
>>>flush. However, if that flush throws an exception, then
>>> triggerBeforeCompletion(defStatus);
>>>never gets called. However, triggerBeforeCompletion is what is =
actually
>>>supposed to release the Hibernate session holder from the current
>>>thread! So in this case, the session (which is totally hosed of =
course),
>>>gets left on the thread. I believe in some environments this wouldn't
>>>matter that much, as the threads don't get resused. In the JBoss =
case,
>>>new requests coming in will get the existing thread, and this time,
>>>SessionFactoryUtils will see the session is there, and try to use it.
>>>Bang, it all blows up...
>>>
>>>So for this code to work properly, what needs to happen is that
>>>triggerBeforeCompletion still needs to be called even if
>>>triggerBeforeCommit fails. While I am ok with writing the code in =
this
>>>method to handle this, I am not 100% sure this is safe in terms of =
all
>>>the other interactions that will happen as a result; mot of this code =
is
>>>your baby with me only having traced through it once in a while. So =
if
>>>you would prefer to resolve this that would be great.
>>>
>>>Unless I am mistaken about this bug, I think it is a pretty serious =
one,
>>>and warrants an almost immediate release of a v1.0.1 of Spring...
>>>
>>>Regards,
>>>Colin
>>>
>>>
>>>Colin Sampaleanu wrote:
>>>
>>>
>>>
>>> =20
>>>
>>>     =20
>>>
>>>>I am tracking down a possible Hibernate resource management issue.
>>>>
>>>>In a running app, some time yesterday, some code, running in a =
wrapped
>>>>transaction with Hibernate handling ORM, encountered an Oracle
>>>>constraint violation and threw an exception. Fine...
>>>>
>>>>But when I log into the app myself now via the web ui and then it =
gets
>>>>a service object to read some data, the service object is wrapped =
with
>>>>a transaction interceptor, and also a hibernate interceptor. The
>>>>Hibernate interceptor is already seeing a Hibernate Session existing
>>>>on the current thread, so it is not creating a new one. Then at the
>>>>end of the transaction, when the Hibernate session is attempted to =
be
>>>>flushed, Hibernate tries to write out the old bad data from =
yesterday.
>>>>
>>>>What this essentially means is that when the error from yesterday
>>>>happened, the session did not get released from the thread, and has
>>>>been sticking around all this time. When I came via struts, I was
>>>>given the same thread as yesterday by the appserver, and the old
>>>>invalid session was still on it. The problem is not that it's =
reusing
>>>>that session, but why it was ever left that the day before.
>>>>
>>>>Will try to duplicate this...
>>>>       =20
>>>>