springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Where's "Resolve Issue" gone in our JIRA?

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

Ahhhhhhhhh Juergen, I noticed something.... I looked at the bottom of =
the
screen and I saw: "Enterprise Edition, Version: 2.6.1-#65" We've been
running 2.5 before. Looks like they've upgraded to the latest version.
Something must have changed.=20

Mike, do you know what the problem might be? Also when I tried to assign =
any
issue "to me", I got a stack trace screen.

Regards,
Dmitriy.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Friday, March 26, 2004 3:36 AM
To: spr...@li...
Subject: [Springframework-developer] Where's "Resolve Issue" gone in our
JIRA?


For some odd reason, "Resolve Issue"  is not available in our JIRA. All
administration options are available to me, so I wonder whether this is =
a
problem with my account or with JIRA. It did work until Wednesday; at =
least
I've not noted any problems.
=20
2 of the 3 issues I've fixed for 1.0.1 are ready to be closed; I can't =
do
this without a "resolve" command...
=20
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=1470&alloc_id638&op=3Dclick
_______________________________________________
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...>]

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ürgen höller [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.
> 
>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ürgen höller [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) {
>               
>TransactionSynchronizationManager.unbindResource(this.sessionFactory);
>                if (this.hibernateTransactionCompletion) {
>                   
>closeSessionIfNecessary(this.sessionHolder.getSession(),
>this.sessionFactory);
>                }
>            }
>        }
>
>        public void afterCompletion(int status) {
>            if (!this.hibernateTransactionCompletion) {
>                Session session = this.sessionHolder.getSession();
>                if (session instanceof SessionImplementor) {
>                    ((SessionImplementor)
>session).afterTransactionCompletion(status == 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ürgen höller [werk3AT] wrote:
>
>  
>
>>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ürgen höller [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ürgen höller [werk3AT] wrote:
>>
>>
>>
>>    
>>
>>>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ürgen höller [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:
>>>
>>>
>>>
>>>  
>>>
>>>      
>>>
>>>>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...
>>>>        
>>>>

[Springframework-developer] Where's "Resolve Issue" gone in our JIRA?

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

For some odd reason, "Resolve Issue"  is not available in our JIRA. All =
administration options are available to me, so I wonder whether this is =
a problem with my account or with JIRA. It did work until Wednesday; at =
least I've not noted any problems.
=20
2 of the 3 issues I've fixed for 1.0.1 are ready to be closed; I can't =
do this without a "resolve" command...
=20
Juergen

Re: [Springframework-developer] Hibernate resource management issue

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

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:

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

Re: [Springframework-developer] POI 2.5 bugged

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

So downgrading to POI 2.0 solves the issue? Can you try to track down =
the issue? If we can double-check that POI 2.5 is the cause, then let's =
ship POI 2.0 with Spring for the time being. (Of course, everyone's free =
to drop in the poi-2.0.jar anyway.)
=20
I experienced some issues with session management on some containers, =
causing Countries' PDF and Excel views to fail because they did not =
participate in the surrounding session. But this doesn't seem to be =
related to your issue, does it?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von JP Pawlak
Gesendet: Fr 26.03.2004 02:20
An: spr...@li...
Betreff: [Springframework-developer] POI 2.5 bugged



Hi,

=20

As I tested my applications with the new 1.0 release, I got a strange =
behaviour with some excel views.

The view is making all the work on the worksheet, but the rendered excel =
document is a new one with the html components of the form view at the =
same controller.

=20

It's difficult to see what part of Spring or POI is responsible, but =
replacing the POI 2.5 jar by the 2.0 renders the expected behaviour.

=20

Jean-Pierre Pawlak

=20

[Springframework-developer] POI 2.5 bugged

[JP P. <jp....@ti...>]

Hi,

 

As I tested my applications with the new 1.0 release, I got a strange
behaviour with some excel views.

The view is making all the work on the worksheet, but the rendered excel
document is a new one with the html components of the form view at the
same controller.

 

It's difficult to see what part of Spring or POI is responsible, but
replacing the POI 2.5 jar by the 2.0 renders the expected behaviour.

 

Jean-Pierre Pawlak

 

Re: [Springframework-developer] Hibernate resource management issue

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

Things are simpler than they appear, and are actually as per my original=20
email. Look at this, from SessionFactoryUtils:
        public void beforeCompletion() throws=20
CleanupFailureDataAccessException {
            if (this.newSession) {
               =20
TransactionSynchronizationManager.unbindResource(this.sessionFactory);
                if (this.hibernateTransactionCompletion) {
                   =20
closeSessionIfNecessary(this.sessionHolder.getSession(),=20
this.sessionFactory);
                }
            }
        }

        public void afterCompletion(int status) {
            if (!this.hibernateTransactionCompletion) {
                Session session =3D this.sessionHolder.getSession();
                if (session instanceof SessionImplementor) {
                    ((SessionImplementor)=20
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=20
never gets called.

So unfortunately this _is_ a serious bug. Any exception during the=20
beforeCommit call (which calls flush) means that the SessionHolder never=20
gets unbound from the thread. Nasty!

Colin


j=FCrgen h=F6ller [werk3AT] wrote:

>Odd - if there's no TransactionManagerLookup, the Session should definit=
ely be closed in afterCompletion.
>=20
>Regarding beforeCompletion, the semantics indeed need to be clarified: I=
 guess it's appropriate to always invoke it, even on beforeCommit failure=
.
>=20
>Juergen
>=20
>
>________________________________
>
>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 i=
ssue
>
>
>
>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 SessionFact=
oryUtils' inner class SessionSynchronization: It assumes that beforeCompl=
etion 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 f=
ace the issue - the bug doesn't have any effects then. Note that you don'=
t need that TransactionManagerLookup when using Spring's JtaTransactionMa=
nager, as Spring will properly apply cache callbacks anyway. A Transactio=
nManagerLookup just adds value when used with EJB CMT or manual JTA, for =
ultra-correct cache callbacks.
>>
>>So essentially, everything should be fine if using HibernateTransaction=
Manager, or JtaTransactionManager without a Hibernate TransactionManagerL=
ookup. 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 repor=
ts first. For the time being, let's suggest to remove the TransactionMana=
gerLookup 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 i=
s
>>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
>>
>>>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
>>
>
>
>
> =20
>

Re: [Springframework-developer] Hibernate resource management issue

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

Odd - if there's no TransactionManagerLookup, the Session should =
definitely be closed in afterCompletion.
=20
Regarding beforeCompletion, the semantics indeed need to be clarified: I =
guess it's appropriate to always invoke it, even on beforeCommit =
failure.
=20
Juergen
=20

________________________________

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:

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

Re: [Springframework-developer] Hibernate resource management issue

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

We're on slightly different pages though. In my case, I am actually not=20
using TransactionManagerLookup... But in my case, because of the=20
exception in the flush in beforeCommit(), beforeCompletion() never gets=20
called (as it would normally). Now I do see that afterCompletion is also=20
supposed to call closeSessionIfNecessary()  (I had actually missed this=20
before), but in my case, it's not getting there. I haven't traced it in=20
a debugger, which is what I will do now, as it seems to me it should get=20
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=20
in any case even if beforeCommit fails. Ultimately, we are still before=20
completion of the transaction, unless you meant it to be only called in=20
the case of no failure.

Colin


j=FCrgen h=F6ller [werk3AT] wrote:

>Colin,
>=20
>Thanks for tracking this down. It's actually a problem with SessionFacto=
ryUtils' inner class SessionSynchronization: It assumes that beforeComple=
tion is called in any case, even if beforeCommit has thrown an exception.=
 However, this just applies if you specified a TransactionManagerLookup i=
n the Hibernate configuration; else, afterCompletion will do the cleanup =
- which will be called in any case.
>=20
>When you remove the Hibernate TransactionManagerLookup, you shouldn't fa=
ce the issue - the bug doesn't have any effects then. Note that you don't=
 need that TransactionManagerLookup when using Spring's JtaTransactionMan=
ager, as Spring will properly apply cache callbacks anyway. A Transaction=
ManagerLookup just adds value when used with EJB CMT or manual JTA, for u=
ltra-correct cache callbacks.
>=20
>So essentially, everything should be fine if using HibernateTransactionM=
anager, or JtaTransactionManager without a Hibernate TransactionManagerLo=
okup. This is clearly something to fix, but I guess we don't need to do a=
n immediate 1.0.1 followup release; I'd like to gather further bug report=
s first. For the time being, let's suggest to remove the TransactionManag=
erLookup from the Hibernate configuration.
>=20
>Juergen
>=20
>
>________________________________
>
>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 i=
ssue
>
>
>
>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
>
>>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
>

Re: [Springframework-developer] Hibernate resource management issue

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

Colin,
=20
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.
=20
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.
=20
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.
=20
Juergen
=20

________________________________

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:

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

Re: [Springframework-developer] Hibernate resource management issue

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

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:

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

Re: [Springframework-developer] Spring Framework 1.0 final released

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

I think Bruce is completely sincere. His views (like mine) are the result of
seeing a lot of projects run into trouble with "heavyweight J2EE".

I reviewed a chapter of his forthcoming book, which was excellent. It was
also very positive towards Spring.

Regards,
Rod

----- Original Message -----
From: "Ken Krebs" <kk...@kk...>
To: "'spring-dev-list'" <spr...@li...>
Sent: Thursday, March 25, 2004 1:21 PM
Subject: [Springframework-developer] Spring Framework 1.0 final released


> It's fitting on this occasion to mention something that occurred at our
> local Madison Wisconsin Java Users Group meeting last night.
>
> Bruce Tate (author of Bitter Java & Bitter EJB) spoke about persistence
> frameworks, specifically EJB CMP, JDO, and Hibernate, providing a look
> under the hood at the underlying strategies and a pretty fair and
> balanced comparison of the advantages and disadvantages of each. At the
> end of the talk he asked the audience if they wanted to hear his take on
> Session Beans. It was then that he started talking about Spring and
> lightweight containers and made the bold prediction that they would
> "take down the J2EE container". A skeptic might say that he was just
> trying to promote his upcoming new book, which will apparently contain a
> lot of Spring content, by saying something controversial but I think
> there's more to it than that ;).
>
>
>
> -------------------------------------------------------
> 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
>

[Springframework-developer] New bean instantiation "type"

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

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

Hello,
  I posted a message to the Spring "help" forum, and it has become more of =
a=20
development idea.  I'd like to copy the two help forum messages here and=20
solicit feedback from Spring developers.  You will find the two messages=20
below.
  Thanks for your consideration.

=46irst message, posted 3/24/04:

<<<<<<<<<<<<

I have two questions regarding Spring's instantiation of beans that are not=
=20
singletons.
 First, let's say I have the following XML:
=20
 ----
 <beans>
 <bean id=3D"a" class=3D"A" singleton=3D"false">
 <property name=3D"b">
 <ref bean=3D"b"/>
 </property>
 </bean>
=20
 <bean id=3D"b" class=3D"B" singleton=3D"false">
 <property name=3D"c">
 <ref bean=3D"c"/>
 </property>
 </bean>
=20
 <bean id=3D"c" class=3D"C" singleton=3D"false">
 <property name=3D"a">
 <ref bean=3D"a"/>
 </property>
 </bean>
 </beans>
 ----
=20
 What will Spring do when I attempt to get "a"? Will this even work? How ma=
ny=20
times will each class be instantiated?
 The second question is similar to the first. Here is another config file:
=20
 ----
 <beans>
 <bean id=3D"a" class=3D"A" singleton=3D"false">
 <property name=3D"b">
 <ref bean=3D"b"/>
 </property>
=20
 <property name=3D"c">
 <ref bean=3D"c"/>
 </property>
 </bean>
=20
 <bean id=3D"b" class=3D"B" singleton=3D"false">
 <property name=3D"c">
 <ref bean=3D"c"/>
 </property>
 </bean>
=20
 <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 f=
or=20
each reference, or once for the entire getBean call?

<<<<<<<<<<<<<<<<<<<<<

I then decided to perform my own tests based on the two examples above.  He=
re=20
is my response:

<<<<<<<<<<<<<<<<<<<<<

Well, I've tested it, and my fears are confirmed. Everytime a non-singleton=
 is=20
referenced in the XML, it is re-instantiated. I haven't looked at Spring's=
=20
source code, but I'm guessing it is using getBean internally to get a bean=
=20
referenced in the XML. This means that the first example never returns. It =
is=20
either stuck in an infinite loop, or it is in infinite recursion, though=20
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 time=
=20
getBean is called, though in that instantiation, referenced objects should=
=20
only be instantiated at most one time.
 Look at the second example. What we would like is the ability to have A, B=
,=20
and C instantiated every time getBean is called, but each class should be=20
instantiated at most once. In other words, the same C reference is passed t=
o=20
both A and B, though all these objects will be reinstantiated the next time=
=20
getBean is called. The behavior we are looking for would be exactly the sam=
e=20
as if all the beans were singletons, but we used a new XmlBeanFactory for=20
every call of getBean. Of course, this is a possible solution to our proble=
m,=20
but I'm guessing it would be terribly ineffecient.
 Right now there are two "types" of bean instantiation: singleton, and=20
non-singleton. Does anyone see value in creating a third type? This new typ=
e=20
would indicate, "create a new instance of the object for each getBean(...)=
=20
call, but never more than one instance, so that all references within the=20
scope of the getBean(...) call get the same instance on reference."=20
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAYxvMdgQy3TUmt38RAtk+AJ4wC9epDPb5wnlBbnwsCmAuB5VVCgCffJ6t
fme2cmOWLhe/YUtegfx02LU=3D
=3DI6nb
=2D----END PGP SIGNATURE-----

[Springframework-developer] Hibernate resource management issue

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

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

Re: [Springframework-developer] Help for Sring AOP

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

Hi,

Please take a look at the relevant section of the Spring manual:
http://www.springframework.org/docs/reference/aop.html

By the way, the developer mailing list is for matters related to
development of spring itself. Usage questions, such as your email below,
are best send to the user mailing list.

Regards,
Colin


cg wrote:

> Hi!
> I met some problem about Spring AOP.I don't know how to write program
> about AOP.Please give me some example code about Spring Aop.Thank you!

RE: [Springframework-developer] Help for Sring AOP

[Kopylenko, D. <dko...@ac...>]

Hi,
 
first of all would be nice to know your name ;-) Then could you please
describe what you're trying to achieve?
 
Regards,
Dmitriy.

-----Original Message-----
From: cg [mailto:cg...@16...] 
Sent: Thursday, March 25, 2004 10:08 AM
To: spr...@li...
Subject: [Springframework-developer] Help for Sring AOP


Hi!
I met some problem about Spring AOP.I don't know how to write program about
AOP.Please give me some example code about Spring Aop.Thank you!

[Springframework-developer] Help for Sring AOP

[cg <cg...@16...>]

DQoNCkhpIQ0KSSBtZXQgc29tZSBwcm9ibGVtIGFib3V0IFNwcmluZyBBT1AuSSBkb24ndCBrbm93
IGhvdyB0byB3cml0ZSBwcm9ncmFtIGFib3V0IEFPUC5QbGVhc2UgZ2l2ZSBtZSBzb21lIGV4YW1w
bGUgY29kZSBhYm91dCBTcHJpbmcgQW9wLlRoYW5rIHlvdSE=

[Springframework-developer] Help for Sring AOP

[cg <cg...@16...>]

SGkhDQpJIG1ldCBzb21lIHByb2JsZW0gYWJvdXQgU3ByaW5nIEFPUC5JIGRvbid0IGtub3cgaG93
IHRvIHdyaXRlIHByb2dyYW0gYWJvdXQgQU9QLlBsZWFzZSBnaXZlIG1lIHNvbWUgZXhhbXBsZSBj
b2RlIGFib3V0IFNwcmluZyBBb3AuVGhhbmsgeW91IQ==

[Springframework-developer] Spring Framework 1.0 final released

[Ken K. <kk...@kk...>]

It's fitting on this occasion to mention something that occurred at our 
local Madison Wisconsin Java Users Group meeting last night.

Bruce Tate (author of Bitter Java & Bitter EJB) spoke about persistence 
frameworks, specifically EJB CMP, JDO, and Hibernate, providing a look 
under the hood at the underlying strategies and a pretty fair and 
balanced comparison of the advantages and disadvantages of each. At the 
end of the talk he asked the audience if they wanted to hear his take on 
Session Beans. It was then that he started talking about Spring and 
lightweight containers and made the bold prediction that they would 
"take down the J2EE container". A skeptic might say that he was just 
trying to promote his upcoming new book, which will apparently contain a 
lot of Spring content, by saying something controversial but I think 
there's more to it than that ;).

Re: [Springframework-developer] Velocity problem in 1.0 final

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

> My main point is that I do not consider it appropriate to support such
> model name conversions in the standard framework. You can subclass
> VelocityView, of course - overriding the renderMergedOutputModel method=
 to
> first process the passed-in model Map and then invoke
> super.renderMergedOutputModel with the processed model Map.
>
> To keep your model names compatible with any view technology (particula=
rly
> ones using expression languages), I strongly recommend to use model nam=
es
> without dots, though.

fair enough - I just hadn't noticed the change when it occurred, and the
other apps I run hadn't triggered it due to not having model names that
contain periods anyway.

This particular app generates part of its model data from an external XML
source streamed over a network and the node values that become the model
names do sometimes contain periods.  I'll just have the controller manage
the conversion.

Cheers!


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

Re: [Springframework-developer] Velocity problem in 1.0 final

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

My main point is that I do not consider it appropriate to support such =
model name conversions in the standard framework. You can subclass =
VelocityView, of course - overriding the renderMergedOutputModel method =
to first process the passed-in model Map and then invoke =
super.renderMergedOutputModel with the processed model Map.

To keep your model names compatible with any view technology =
(particularly ones using expression languages), I strongly recommend to =
use model names without dots, though.

Juergen


-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT]=20
Sent: Thursday, March 25, 2004 1:06 PM
To: 'spr...@li...'
Subject: Re: [Springframework-developer] Velocity problem in 1.0 final


I've removed this because I consider model names with dots something to =
avoid: Such model names do not work with the JSTL or FreeMarker either, =
so I suggest to use different model names rather than adding special =
conversions to Spring's templating support. Effectively, a "." -> "_" =
conversion is a workaround that we'd need to add to JSTL and FreeMarker =
too for consistency: Frankly, I don't see the point in this - let's =
recommend model names without dots, usable with any view technology.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Darren Davison
Sent: Thursday, March 25, 2004 12:59 PM
To: spr...@li...
Subject: [Springframework-developer] Velocity problem in 1.0 final



I've just dropped a 1.0 final spring.jar into one of my projects that =
uses
Velocity and it now fails due to a change made in VelocityView (CVS
revision 1.24)

Prior to this version, the velocity context was initialized with:

Context velocityContext =3D new VelocityContext();
VelocityEngineUtils.exposeModelAsContextAttributes(model, =
velocityContext);


now, it's done with:

Context velocityContext =3D new VelocityContext(model);

and the relevant conversion method from VelocityEngineUtils has been =
removed.

What this means is any model object with a period (.) in the name is not
altered to a velocity friendly underscore character (_) which
VelocityEngineUtils used to do.

Is there a reason this was done, or is there an alternative conversion
method that I've overlooked?  Velocity can still not handle names with
periods so now any application that potentially adds such keys to the
model map will break (as mine just has!) when Velocity is the view
technology.

Regards,

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



-------------------------------------------------------
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] Velocity problem in 1.0 final

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

I've removed this because I consider model names with dots something to =
avoid: Such model names do not work with the JSTL or FreeMarker either, =
so I suggest to use different model names rather than adding special =
conversions to Spring's templating support. Effectively, a "." -> "_" =
conversion is a workaround that we'd need to add to JSTL and FreeMarker =
too for consistency: Frankly, I don't see the point in this - let's =
recommend model names without dots, usable with any view technology.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Darren Davison
Sent: Thursday, March 25, 2004 12:59 PM
To: spr...@li...
Subject: [Springframework-developer] Velocity problem in 1.0 final



I've just dropped a 1.0 final spring.jar into one of my projects that =
uses
Velocity and it now fails due to a change made in VelocityView (CVS
revision 1.24)

Prior to this version, the velocity context was initialized with:

Context velocityContext =3D new VelocityContext();
VelocityEngineUtils.exposeModelAsContextAttributes(model, =
velocityContext);


now, it's done with:

Context velocityContext =3D new VelocityContext(model);

and the relevant conversion method from VelocityEngineUtils has been =
removed.

What this means is any model object with a period (.) in the name is not
altered to a velocity friendly underscore character (_) which
VelocityEngineUtils used to do.

Is there a reason this was done, or is there an alternative conversion
method that I've overlooked?  Velocity can still not handle names with
periods so now any application that potentially adds such keys to the
model map will break (as mine just has!) when Velocity is the view
technology.

Regards,

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



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

[Springframework-developer] Velocity problem in 1.0 final

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

I've just dropped a 1.0 final spring.jar into one of my projects that use=
s
Velocity and it now fails due to a change made in VelocityView (CVS
revision 1.24)

Prior to this version, the velocity context was initialized with:

Context velocityContext =3D new VelocityContext();
VelocityEngineUtils.exposeModelAsContextAttributes(model, velocityContext=
);


now, it's done with:

Context velocityContext =3D new VelocityContext(model);

and the relevant conversion method from VelocityEngineUtils has been remo=
ved.

What this means is any model object with a period (.) in the name is not
altered to a velocity friendly underscore character (_) which
VelocityEngineUtils used to do.

Is there a reason this was done, or is there an alternative conversion
method that I've overlooked?  Velocity can still not handle names with
periods so now any application that potentially adds such keys to the
model map will break (as mine just has!) when Velocity is the view
technology.

Regards,

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

[Springframework-developer] Re: [Springframework-user] Spring Framework 1.0 final released

[Bruno T. <bt...@al...>]

Dear Spring developpers, and Rod,


Already a lot of things has been said but I really wanted to send you my 
congratulations for your work. You've reached the starting goal : make a 
framework well layered, non inclusive, and powerfull. It's now 6 months 
that I began to use it, and it's a real pleasure, so you made J2EE 
developpment fun !

Again thanks a lot.

Bruno THOMAS

[Springframework-developer] RE: [Springframework-user] Spring Framework 1.0 final released

[Shishir K. S. <sk...@sy...>]

Is the ibatis-common.jar the correct version  in the spring with =
dependencies download ? The jar is missing the ReaderInputStream.class =
which is a 2.0 req.

Thanks
Shishir =20

 =20

-----Original Message-----
From: spr...@li... =
[mailto:spr...@li...] On Behalf Of =
j=FCrgen h=F6ller [werk3AT]
Sent: Wednesday, March 24, 2004 7:19 PM
To: spr...@li...; =
spr...@li...
Subject: [Springframework-user] Spring Framework 1.0 final released

***** Look outside, Spring is here! ***** (for the northern hemisphere, =
at least ;-)
=20
=20
Dear Spring community,
=20
I'm pleased to announce that Spring Framework 1.0 final has just been =
released. Thanks to all contributors and early adopters that have =
followed our 1.0 milestones and release candidates: Spring wouldn't be =
as mature as it is without you!
=20
=20
1. SCOPE
=20
Spring 1.0 is a complete Java/J2EE application framework, covering the =
following functionality:
=20
* the most sophisticated lightweight container available today, with =
various flavors of setter and constructor injection
* AOP interception framework based on the AOP Alliance interfaces, =
integrated with the core container
* JNDI support classes, allowing for easy wiring of Spring-managed beans =
with JNDI-located objects
* application context concept, providing resource loading and message =
access abstractions
* generic transaction management with pluggable strategies, supporting =
declarative and programmatic demarcation
* support for source-level metadata, with Commons Attributes as default =
implementation (e.g. for transaction attributes)
* generic DAO support, providing a generic data access exception =
hierarchy for use with any data access strategy
* JDBC abstraction that simplifies resource and error handling, also =
covering BLOB/CLOB support
* Hibernate support, providing SessionFactory management and =
transaction-scoped ThreadLocal Sessions
* support classes for JDO 1.0 and iBATIS SQL Maps 1.3/2.0, integrated =
with Spring's transaction management
* mail sender abstraction, with special support for JavaMail including =
convenient handling of file attachments
* scheduling support for Quartz and Timer, making it easy to invoke =
methods of Spring-managed beans
* remoting support for RMI, JAX-RPC and Caucho's Hessian/Burlap, for =
easy exposure of Spring-managed beans
* convenience classes for accessing and implementing EJBs, both local =
and remote
* web application context, for loading a Spring application context in a =
web environment
* flexible web MVC framework, built on strategy interfaces and =
integrated with various view technologies
=20
A unique benefit of Spring is the ability to apply declarative =
transactions to any POJO, with JTA or a local transaction strategy: This =
allows to have lightweight transactional business objects in any sort of =
environment, for example in a web app running on plain Tomcat. Spring's =
transaction management is also capable of managing associated resources =
like Hibernate Sessions, avoiding the burden of custom ThreadLocal =
Sessions.
=20
Building on the resource management infrastructure, Spring's =
HibernateTemplate significantly simplifies the implementation of =
Hibernate-based DAOs, reducing typical data access operations to single =
statements. A similar level of convenience is available for JDBC in the =
form of Spring's JdbcTemplate, and for iBATIS SQL Maps 1.3/2.0 in the =
form of SqlMapTemplate respectively SqlMapClientTemplate.
=20
An important characteristic of Spring is that many of its features can =
be used individually, without the need to adopt an architecture that's =
completely based on Spring. Furthermore, a Spring-managed middle tier =
and all the functionality it provides can be reused in any sort of =
environment, be it a J2EE web application with a Spring web MVC, Struts, =
WebWork or Tapestry web tier, or a standalone application with a Swing =
user interface.
=20
=20
2. SAMPLES AND USAGES
=20
The Spring distribution comes with numerous sample applications. The =
"-with-dependencies" download includes all third-party libraries that =
are necessary for building an running them.
=20
* our JPetStore, adapting the iBATIS JPetStore with a Spring-managed =
middle tier and alternative Spring/Struts web tiers
* Petclinic, a simple database-driven web application that offers =
alternative Hibernate/JDBC data access strategies
* Countries, a web app that illustrates locale and theme handling, and =
the generation of PDF and Excel web views
* Image Database, a one-screen web app that illustrates BLOB/CLOB =
handling and Velocity/FreeMarker web views
* Tiles Example, demonstrating the use of Tiles with Spring's web MVC =
framework
=20
Spring is already used in a significant number of production =
applications, including mission-critical applications. Current adopters =
include a number of large banks and health care organizations in Europe =
and the US. Noteworthy usages of Spring in publically visible =
applications are:
=20
* Matt Raible's AppFuse =
(http://raibledesigns.com/wiki/Wiki.jsp?page=3DAppFuse) application =
skeleton, adopting Spring as middle tier framework with a Struts web =
tier
* Atlassian's new product Confluence =
(http://www.atlassian.com/software/confluence), built on a Spring middle =
tier and a WebWork2 web tier
=20
=20
3. UPGRADING
=20
Users upgrading from a Spring 1.0 milestone or release candidate, please =
see the changelog; there have been quite a few refinements in the =
details. Among the changes since 1.0 RC2 are:
=20
* AOP support upgraded to AOP Alliance 1.0
* more sophisticated handling of indexed and mapped properties in =
BeanWrapperImpl
* new ResourceLoader interface, extended by the ApplicationContext =
interface
* ReloadableResourceBundleMessage supports configurable character =
encodings
* MimeMessageHelper supports configurable character encodings
* JdbcTemplate has new generic "execute" methods and refined "query" =
methods
* iBATIS SQL Maps 2.0 support upgraded to SQL Maps 2.0 RC1
* added support for FreeMarker 2.3
=20
Please note the following upgrade issues with respect to the AOP =
support:
=20
* you have to update your aopalliance.jar
* AdvisorAutoProxyCreator was renamed to DefaultAdvisorAutoProxyCreator
* TransactionAttributeSourceTransactionAroundAdvisor was renamed to =
TransactionAttributeSourceAdvisor
* custom Advisor implementations: getAdvice() now returns =
org.aopalliance.aop.Advice rather than Object
* if you implemented org.springframework.aop.MethodAfterReturningAdvice, =
replace with AfterReturningAdvice (no change in method signature)

=20
Regards,
=20
Juergen
=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-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user