springframework-developer — Spring Framework developers list

Re: [Springframework-developer] order of lookup-method in bean declaration important?

[Christopher H. <cj_...@ho...>]

Juergen,

I get the same problem when using spring 1.1.2. It is caused by the 
definition of the bean element within the spring-bean.dtd within the 
spring-core.jar:

<!ELEMENT bean (
	description?,
	(constructor-arg | property)*,
	(lookup-method | replaced-method)*
)>

Looks as if the spring-bean.dtd has been changed within the 1.2.

Hope that helps.

Chris.

From: "Juergen Hoeller" <ju...@in...>
Reply-To: spr...@li...
To: <spr...@li...>
Subject: Re: [Springframework-developer] order of lookup-method in bean 
declaration important?
Date: Mon, 23 May 2005 11:59:04 +0200

Tim,

The order of <bean> sub elements should not matter, with the sole exception
of <description> which needs to be first. What kind of error do you get when
you place your <lookup-method> tag before your <property> tag?

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Tim Kettering
Sent: Thursday, May 19, 2005 11:21 PM
To: spr...@li...
Subject: [Springframework-developer] order of lookup-method in bean
declaration important?



Hi,

I was looking into integrating lookup-method in my context, and I was using
the reference found here:

http://static.springframework.org/spring/docs/1.2/reference/beans.html#beans
-factory-method-injection

After much tussling around with some weird XML error, and looking at some
other examples pasted in the forums, I moved the <lookup-method> tag to
appear after the <property> tags, and it all worked after that.

So I think the example in the reference is misleading, since it places the
<lookup-method> tag before the <property> tag, which apparently does not
work for me (in Spring 1.2).

So, does the order matter?  If so, the reference example should be updated
and the text to clearly state in what order it should appear in the <bean>
declaration.

Thanks.

-tim



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Preparing for release 1.2.1

[Juergen H. <ju...@in...>]

Everybody,

Spring 1.2.1 is essentially ready and scheduled for release this Friday.
This is almost entirely a bugfix and internal refinement release, mainly in
the following areas: constructor resolution, transaction management,
Hibernate3 support, HTML escaping. See changelog.txt for details.

One minor new feature is support for enabling Hibernate3 filters for the
scope of a specific operation, deactivating it right afterwards. This is
available as "filterNames" property on HibernateAccessor, i.e. on
HibernateTemplate and HibernateInterceptor.

Please give the current CVS contents or the current nightly snapshots a try,
in particular to test whether the Hibernate3 integration works properly in
all scenarios. The reimplemented HTML escaping was committed yesterday
evening, so won't be available before the next nightly snapshot.

Cheers,

Juergen

Re: [Springframework-developer] order of lookup-method in bean declaration important?

[Juergen H. <ju...@in...>]

Tim,

The order of <bean> sub elements should not matter, with the sole exception
of <description> which needs to be first. What kind of error do you get when
you place your <lookup-method> tag before your <property> tag?

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Tim Kettering
Sent: Thursday, May 19, 2005 11:21 PM
To: spr...@li...
Subject: [Springframework-developer] order of lookup-method in bean
declaration important?



Hi,

I was looking into integrating lookup-method in my context, and I was using
the reference found here:

http://static.springframework.org/spring/docs/1.2/reference/beans.html#beans
-factory-method-injection

After much tussling around with some weird XML error, and looking at some
other examples pasted in the forums, I moved the <lookup-method> tag to
appear after the <property> tags, and it all worked after that.

So I think the example in the reference is misleading, since it places the
<lookup-method> tag before the <property> tag, which apparently does not
work for me (in Spring 1.2).

So, does the order matter?  If so, the reference example should be updated
and the text to clearly state in what order it should appear in the <bean>
declaration.

Thanks.

-tim



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] CSS-File for reference documentation is missing

[Roland H. <Rol...@co...>]

Hi,

some minor problem with the website: the stylesheet for the reference
documentation

http://static.springframework.org/spring/docs/1.2/styles/html.css

is missing as well as for the 1.1.5 docs.

Sorry for posting it here, I couldn't find an appropriate jira category
for this issue...

ciao...
-- 
                                                        ...roland huss
                                                             consol.de

[Springframework-developer] Confluence logo

[Erwin V. <erw...@er...>]

The Spring logo on the Confluence site seems to have gone missing the last
couple of days (left top corner):

http://opensource.atlassian.com/confluence/spring/homepage.action

Apparently the file http://repository.atlassian.com/spring_jira_logo.gif is 
no longer there.

Can somebody fix that?

Erwin

[Springframework-developer] Spring Web Flow PR3 Released

[Keith D. <ke...@in...>]

Dear Spring Community,

 

I'm pleased to announce the release of Spring Web Flow Preview 3.  This is a
major new release with a substantial number of new features: both in terms
of power and convenience.  This release is considered stable for development
use.

 

To download, access:
http://sourceforge.net/project/showfiles.php?group_id=73357
<http://sourceforge.net/project/showfiles.php?group_id=73357&package_id=1485
17> &package_id=148517

 

Note: there are a few incompatible changes between PR2 and PR3.  For a
listing and a porting guide, access the change log here:
http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Change+Log

 

Contained within this release are a number of new and noteworthy
enhancements.  Here are some of them:

 

View State Enhancements

 

-          Each view state may now be configured with one or more setup
actions.  This action is executed after the state is entered but before
control is returned to the client for response rendering.  This reduces (and
in many cases eliminates) the need for setup action states, making for more
concise flow definitions.

 

-          Each view state may now select the view to render and all
supporting model data in a fully dynamic, pluggable fashion using the new
ViewDescriptorCreator strategy.

 

-          Powerful redirect expressions are now supported, with
full-support for resolving redirect parameters in a dynamic fashion from the
flow RequestContext.

 

Here is an example of these new features in action:

 

Setup actions

 

<view-state id="displayCriteria" view="criteriaView">

            <setup bean="searchFormAction" method="setupForm"/>

            <transition on="submit" to="executeQuery">

                  <action bean="searchFormAction" method="bindAndValidate"/>

            </transition>

</view-state>

 

Redirect expressions

 

<end-state id="end" view="redirect:/myFlow.htm?input=${flowScope.input}"/>

 

Subflow Attribute Mapping Enhancements

 

-          Subflow input and output mapping policies are now fully
configurable via a XML flow definition.

 

-          Expressions may also be specified that resolve subflow input
attribute values in a dynamic fashion.

 

For example:

 

<attribute-mapper>

            <input value="${sourceEvent.parameters.id}" as="id"
type="long"/>

</attribute-mapper>

 

The expression language used is also pluggable - by default web flow will
try OGNL, if it's not found on the classpath it'll use Spring's BeanWrapper.

 

Annotated Definition Objects

 

-          In addition to action execution parameters, each core definition
object in the system--Flow, State, and Transition---can now be annotated
with arbitrary property metadata.  Such properties are specifiable in the
webflow xml definition using the "property" element, with full support for
from-string type conversion with convenient type aliasing.

 

For example:

 

<transition on="submit" to="executeQuery">

            <property name="submitPressed" value="true" type="boolean"/>

</transition>

 

In this case this 'submitPressed' boolean property would be made available
to this transition's target state after entering for reasoning.

 

Enhanced Flow Execution Listener Callbacks

 

-          Listeners responding to the lifecycle of an executing flow now
have more hooks to insert custom logic-notification now happens when a flow
is starting, started, paused, resumed, entering a new state, entered a new
state, or ended---with veto capability for proposed flow state changes (to
facilitate state precondition checks, for example).

 

---

 

These are just some of the new features of this release.  For a full list of
changes, see
http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Change+Log

 

As always, we very much value your feedback.  One or two more PR releases to
go and we'll be at 1.0 final! :-)

 

Cheers,

 

Keith Donald

Erwin Vervaet

 

Interface21 - http://www.springframework.com
<http://www.springframework.com/> 

Re: [Springframework-developer] Spring 1.2 Spring JTA tx timeout, tx rolls back, but no exception thrown (another race condition)

[Dave B. <dba...@on...>]

Hi Juergen ,

That's great. I will give it a try tomorrow.

Dave

Juergen Hoeller wrote:

>Dave,
>
>I've already finished the reworking: AbstractPlatformTransactionManager
>discriminated between a "local" and a "global" rollback-only flag now, which
>was fortunately straightforward to do.
>
>"local" refers to a TransactionStatus.setRollbackOnly() call by the
>application, which leads to a silent rollback (usually, the application will
>throw an appropriate exception).
>
>"global" refers to the UserTransaction or resource holder being marked as
>rollback-only, which can only happen through the transaction coordinator.
>One example for this is a transaction timeout.
>
>There is one side effect, though: If you have an outer and an inner
>transaction and call TransactionStatus.setRollbackOnly() on the inner
>transaction without throwing an exception, you got a silent rollback of the
>outer transaction before. Now, the outer transaction will throw an
>UnexpectedRollbackException instead.
>
>I guess it's more appropriate to throw an UnexpectedRollbackException here
>in any case, to avoid surprises for callers of the outer transaction.
>Usually, the inner transaction will throw an exception anyway, so the outer
>transaction will simply rollback and propagate that exception.
>
>In total, I'm happy with the new semantics. Rollbacks will always lead to an
>exception, unless the local TransactionStatus object received a
>setRollbackOnly() call from the application. The slight change in semantics
>should not be an issue, as I do not expect any application to rely on such
>silent rollbacks of outer transactions.
>
>I'll commit this today; it should be available in the next nightly build.
>Please give this refined behavior a try and let me know how it works for
>you!
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Dave Ballard
>Sent: Sunday, May 22, 2005 1:22 AM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Spring 1.2 Spring JTA tx
>timeout, tx rolls back, but no exception thrown (another race condition)
>
>
>Hi Juergen,
>
>Thanks for checking into this. Does look a little ugly. Hopefully you'll
>find a way to tell the difference between the two different rollback
>situations (or to inquire if in fact a timeout has occurred). Currently
>this is a show-stopper for me. Although this type of timeout won't
>happen frequently, it will happen, and the consequences will be a little
>difficult to track down because of the lack of an exception.
>
>Thanks again for your help,
>Dave
>
>Juergen Hoeller wrote:
>
>  
>
>>Good point - thanks for reporting this! JTA implementations seem to mark
>>transaction as rollback-only when they have timed out, without further
>>indication. So unless you attempt an actual resource operation after the
>>timeout, there is no guarantee than an exception gets thrown before commit.
>>
>>If Spring discovers a rollback-only status, it assumes that the application
>>has set the transaction to rollback-only and triggers a silent rollback.
>>This will usually happen when TransactionStatus.setRollbackOnly() has been
>>called, instead of configuring a rollback rule, with an application-level
>>exception getting thrown.
>>
>>In the case of a JTA timeout, the rollback-only marker comes from the JTA
>>subsystem, though. Spring effectively misinterprets that marker as driven
>>    
>>
>by
>  
>
>>the application, which leads to an inappropriate silent reaction. I'll fix
>>that for Spring 1.2.1, although it's unfortunately not that trivial for the
>>general case.
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Dave Ballard
>>Sent: Friday, May 20, 2005 10:44 PM
>>To: spr...@li...
>>Subject: [Springframework-developer] Spring 1.2 Spring JTA tx timeout,
>>tx rolls back, but no exception thrown (another race condition)
>>
>>
>>Hi Juergen,
>>
>>Using unpatched Spring 1.2 on WebLogic 6.1. I've defined a
>>Spring-managed service bean, with the following transaction manager and
>>transaction interceptor beans:
>>
>> <bean id="MyTransactionManager"
>>class="org.springframework.transaction.jta.JtaTransactionManager">
>>   <property
>>name="transactionManagerName"><value>java:comp/UserTransaction</value></pro
>>    
>>
>p
>  
>
>>erty>
>> </bean>
>>
>> <bean id="MyTransactionInterceptor"
>>class="org.springframework.transaction.interceptor.TransactionInterceptor">
>>   <property name="transactionManager"><ref
>>bean="MyTransactionManager"/></property>
>>   <property name="transactionAttributeSource">
>>     <value>
>>       PaymentService.commit=PROPAGATION_REQUIRED,-Exception
>>     </value>
>>   </property>
>> </bean>
>>
>>The transactional demarcation causes a commit when the method succeeds,
>>and causes a rollback when an exception is thrown (and throws the
>>exception), as expected. However, if I introduce a 40 second sleep in
>>the method, the transaction rolls back as expected, but sometimes no
>>exception is thrown. In the case where no exception is thrown, I can see
>>in the Spring log:
>>
>>WARN 14:45:03,156 [ExecuteThread: '30' for queue: 'default']
>>[edemo_acme] (EjbUtils.java:626) - START SLEEP 40:
>>PaymentServiceImpl.commit() 40 seconds......
>>WARN 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>>[edemo_acme] (EjbUtils.java:633) - DONE  SLEEP 40:
>>PaymentServiceImpl.commit() 40 seconds......
>>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>>[edemo_acme] (TransactionAspectSupport.java:258) - Invoking commit for
>>transaction on PaymentService.commit
>>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>>[edemo_acme] (AbstractPlatformTransactionManager.java:382) -
>>Transactional code has requested rollback
>>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>>[edemo_acme] (AbstractPlatformTransactionManager.java:542) - Triggering
>>beforeCompletion synchronization
>>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>>[edemo_acme] (TransactionSynchronizationManager.java:177) - Removed
>>value [org.springframework.orm.hibernate.SessionHolder@57f820] for key
>>[net.sf.hibernate.impl.SessionFactoryImpl@39569e] from thread
>>[ExecuteThread: '30' for queue: 'default']
>>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>>[edemo_acme] (SessionFactoryUtils.java:730) - Closing Hibernate Session
>>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>>[edemo_acme] (AbstractPlatformTransactionManager.java:463) - Initiating
>>transaction rollback
>>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>>[edemo_acme] (JtaTransactionManager.java:719) - Rolling back JTA
>>    
>>
>transaction
>  
>
>>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>>[edemo_acme] (AbstractPlatformTransactionManager.java:572) - Triggering
>>afterCompletion synchronization
>>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>>[edemo_acme] (TransactionSynchronizationManager.java:252) - Clearing
>>transaction synchronization
>>INFO 14:45:43,171 [ExecuteThread: '30' for queue: 'default']
>>[edemo_acme] (PaymentCommit.java:167) - PERFORMANCE END   PaymentCommit
>>
>>This is an intermittent problem that occurs in both 1.1.5 and 1.2. I run
>>the same test over and over, and while it always rolls back, it only
>>sometimes throws an exception. In the case where it does throw an
>>exception, the log is different:
>>
>>WARN 15:18:54,109 [ExecuteThread: '31' for queue: 'default']
>>[edemo_acme] (EjbUtils.java:626) - START SLEEP 40:
>>PaymentServiceImpl.commit() 40 seconds......
>>WARN 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>>[edemo_acme] (EjbUtils.java:633) - DONE  SLEEP 40:
>>PaymentServiceImpl.commit() 40 seconds......
>>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>>[edemo_acme] (TransactionAspectSupport.java:241) - Invoking commit for
>>transaction on method 'commit' in class [PaymentService]
>>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>>[edemo_acme] (AbstractPlatformTransactionManager.java:523) - Triggering
>>beforeCommit synchronization
>>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>>[edemo_acme] (SessionFactoryUtils.java:809) - Flushing Hibernate session
>>on transaction synchronization
>>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>>[edemo_acme] (SQLErrorCodeSQLExceptionTranslator.java:225) - Unable to
>>translate SQLException with errorCode '0', will now try the fallback
>>translator
>>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>>[edemo_acme] (SQLStateSQLExceptionTranslator.java:74) - Translating
>>SQLException with SQLState 'null' and errorCode '0' and message [The
>>transaction is no longer active (status = Rolled back.
>>[Reason=weblogic.transaction.internal.TimedOutException: Transaction
>>timed out after 28 seconds
>>[snip]
>>
>>This appears to be another race condition. In the case where the
>>exception is thrown, the transaction has not yet been flagged as
>>rollback-only. The code proceeds to attempt a hibernate flush(), and
>>this causes a SQLException(TimedOutException) to be thrown.
>>
>>In the first case where no exception is thrown, the transaction has
>>already been flagged rollback-only, so the code never calls hibernate
>>flush, and simply returns w/o an exception after rolling back the tx.
>>
>>This is a pretty serious problem for my application because the calling
>>code has no idea that the transaction rolled back.
>>
>>Thanks,
>>Dave
>>
>>
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by Oracle Space Sweepstakes
>>Want to be the first software developer in space?
>>Enter now for the Oracle Space Sweepstakes!
>>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by Oracle Space Sweepstakes
>>Want to be the first software developer in space?
>>Enter now for the Oracle Space Sweepstakes!
>>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>>    
>>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

[Springframework-developer] webflow pr3 due out later day

[Keith D. <ke...@in...>]

Guys,

 

Spring Web Flow PR3 is due out later today.most likely late tonight after I
arrive in Baltimore.

 

This is a major release with a lot of new features, so if I could get yall
to test and/or review before we ship that'd be excellent:

 

Here is a summary of the new stuff with PR3:

 

-          dynamic (pluggable) view selection and model population
capability for view states

-          view state setup actions

-          redirect expressions

-          subflow attribute mapping expressions

-          subflow-state attribute mapping capability directly within xml
(input/output elements)

-          extensible properties for all definition objects: flow, state,
transition, action execution

-          support for primitive/complex property types (besides string)
using new type conversion infrastructure.

-          Enhanced flow execution listener lifecycle methods

-          pluggable expression evaluation capability (see new package
org.springframework.binding.expression! PLEASE REVIEW - this is proposed for
core)

-          pluggability for all core definition objects: flow, state,
transition, action

-          pluggability of transaction synchronizer interface for custom
application-transaction demarcation

-          general refining and polishing - package structure should be
stable now

-     enhanced Struts integration

 

This is the power release.  PR4 will be the release that builds on the new
power provided here (particularly the ability to annotate just about
everything, and the dynamic view stuff) to add additional convenience
features for common cases, and add full JSF integration.

 

Juergen-please note the new org.springframework.binding.expression package,
a common abstraction for Expression parsing and evaluation.

 

Keith

 

Re: [Springframework-developer] Spring 1.2 Spring JTA tx timeout, tx rolls back, but no exception thrown (another race condition)

[Juergen H. <ju...@in...>]

Dave,

I've already finished the reworking: AbstractPlatformTransactionManager
discriminated between a "local" and a "global" rollback-only flag now, which
was fortunately straightforward to do.

"local" refers to a TransactionStatus.setRollbackOnly() call by the
application, which leads to a silent rollback (usually, the application will
throw an appropriate exception).

"global" refers to the UserTransaction or resource holder being marked as
rollback-only, which can only happen through the transaction coordinator.
One example for this is a transaction timeout.

There is one side effect, though: If you have an outer and an inner
transaction and call TransactionStatus.setRollbackOnly() on the inner
transaction without throwing an exception, you got a silent rollback of the
outer transaction before. Now, the outer transaction will throw an
UnexpectedRollbackException instead.

I guess it's more appropriate to throw an UnexpectedRollbackException here
in any case, to avoid surprises for callers of the outer transaction.
Usually, the inner transaction will throw an exception anyway, so the outer
transaction will simply rollback and propagate that exception.

In total, I'm happy with the new semantics. Rollbacks will always lead to an
exception, unless the local TransactionStatus object received a
setRollbackOnly() call from the application. The slight change in semantics
should not be an issue, as I do not expect any application to rely on such
silent rollbacks of outer transactions.

I'll commit this today; it should be available in the next nightly build.
Please give this refined behavior a try and let me know how it works for
you!

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Dave Ballard
Sent: Sunday, May 22, 2005 1:22 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring 1.2 Spring JTA tx
timeout, tx rolls back, but no exception thrown (another race condition)


Hi Juergen,

Thanks for checking into this. Does look a little ugly. Hopefully you'll
find a way to tell the difference between the two different rollback
situations (or to inquire if in fact a timeout has occurred). Currently
this is a show-stopper for me. Although this type of timeout won't
happen frequently, it will happen, and the consequences will be a little
difficult to track down because of the lack of an exception.

Thanks again for your help,
Dave

Juergen Hoeller wrote:

>Good point - thanks for reporting this! JTA implementations seem to mark
>transaction as rollback-only when they have timed out, without further
>indication. So unless you attempt an actual resource operation after the
>timeout, there is no guarantee than an exception gets thrown before commit.
>
>If Spring discovers a rollback-only status, it assumes that the application
>has set the transaction to rollback-only and triggers a silent rollback.
>This will usually happen when TransactionStatus.setRollbackOnly() has been
>called, instead of configuring a rollback rule, with an application-level
>exception getting thrown.
>
>In the case of a JTA timeout, the rollback-only marker comes from the JTA
>subsystem, though. Spring effectively misinterprets that marker as driven
by
>the application, which leads to an inappropriate silent reaction. I'll fix
>that for Spring 1.2.1, although it's unfortunately not that trivial for the
>general case.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Dave Ballard
>Sent: Friday, May 20, 2005 10:44 PM
>To: spr...@li...
>Subject: [Springframework-developer] Spring 1.2 Spring JTA tx timeout,
>tx rolls back, but no exception thrown (another race condition)
>
>
>Hi Juergen,
>
>Using unpatched Spring 1.2 on WebLogic 6.1. I've defined a
>Spring-managed service bean, with the following transaction manager and
>transaction interceptor beans:
>
>  <bean id="MyTransactionManager"
>class="org.springframework.transaction.jta.JtaTransactionManager">
>    <property
>name="transactionManagerName"><value>java:comp/UserTransaction</value></pro
p
>erty>
>  </bean>
>
>  <bean id="MyTransactionInterceptor"
>class="org.springframework.transaction.interceptor.TransactionInterceptor">
>    <property name="transactionManager"><ref
>bean="MyTransactionManager"/></property>
>    <property name="transactionAttributeSource">
>      <value>
>        PaymentService.commit=PROPAGATION_REQUIRED,-Exception
>      </value>
>    </property>
>  </bean>
>
>The transactional demarcation causes a commit when the method succeeds,
>and causes a rollback when an exception is thrown (and throws the
>exception), as expected. However, if I introduce a 40 second sleep in
>the method, the transaction rolls back as expected, but sometimes no
>exception is thrown. In the case where no exception is thrown, I can see
>in the Spring log:
>
> WARN 14:45:03,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (EjbUtils.java:626) - START SLEEP 40:
>PaymentServiceImpl.commit() 40 seconds......
> WARN 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (EjbUtils.java:633) - DONE  SLEEP 40:
>PaymentServiceImpl.commit() 40 seconds......
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (TransactionAspectSupport.java:258) - Invoking commit for
>transaction on PaymentService.commit
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (AbstractPlatformTransactionManager.java:382) -
>Transactional code has requested rollback
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (AbstractPlatformTransactionManager.java:542) - Triggering
>beforeCompletion synchronization
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (TransactionSynchronizationManager.java:177) - Removed
>value [org.springframework.orm.hibernate.SessionHolder@57f820] for key
>[net.sf.hibernate.impl.SessionFactoryImpl@39569e] from thread
>[ExecuteThread: '30' for queue: 'default']
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (SessionFactoryUtils.java:730) - Closing Hibernate Session
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (AbstractPlatformTransactionManager.java:463) - Initiating
>transaction rollback
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (JtaTransactionManager.java:719) - Rolling back JTA
transaction
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (AbstractPlatformTransactionManager.java:572) - Triggering
>afterCompletion synchronization
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (TransactionSynchronizationManager.java:252) - Clearing
>transaction synchronization
> INFO 14:45:43,171 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (PaymentCommit.java:167) - PERFORMANCE END   PaymentCommit
>
>This is an intermittent problem that occurs in both 1.1.5 and 1.2. I run
>the same test over and over, and while it always rolls back, it only
>sometimes throws an exception. In the case where it does throw an
>exception, the log is different:
>
> WARN 15:18:54,109 [ExecuteThread: '31' for queue: 'default']
>[edemo_acme] (EjbUtils.java:626) - START SLEEP 40:
>PaymentServiceImpl.commit() 40 seconds......
> WARN 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>[edemo_acme] (EjbUtils.java:633) - DONE  SLEEP 40:
>PaymentServiceImpl.commit() 40 seconds......
>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>[edemo_acme] (TransactionAspectSupport.java:241) - Invoking commit for
>transaction on method 'commit' in class [PaymentService]
>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>[edemo_acme] (AbstractPlatformTransactionManager.java:523) - Triggering
>beforeCommit synchronization
>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>[edemo_acme] (SessionFactoryUtils.java:809) - Flushing Hibernate session
>on transaction synchronization
>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>[edemo_acme] (SQLErrorCodeSQLExceptionTranslator.java:225) - Unable to
>translate SQLException with errorCode '0', will now try the fallback
>translator
>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>[edemo_acme] (SQLStateSQLExceptionTranslator.java:74) - Translating
>SQLException with SQLState 'null' and errorCode '0' and message [The
>transaction is no longer active (status = Rolled back.
>[Reason=weblogic.transaction.internal.TimedOutException: Transaction
>timed out after 28 seconds
>[snip]
>
>This appears to be another race condition. In the case where the
>exception is thrown, the transaction has not yet been flagged as
>rollback-only. The code proceeds to attempt a hibernate flush(), and
>this causes a SQLException(TimedOutException) to be thrown.
>
>In the first case where no exception is thrown, the transaction has
>already been flagged rollback-only, so the code never calls hibernate
>flush, and simply returns w/o an exception after rolling back the tx.
>
>This is a pretty serious problem for my application because the calling
>code has no idea that the transaction rolled back.
>
>Thanks,
>Dave
>
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] FAILED BUILD: sparc-solaris1 (last 30 lines included)

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

1116748308
FAILED
    [junit] Testcase: testCannotCreateTransaction took 0,011 sec
    [junit] Testcase: testCannotCommitTransaction took 0,003 sec
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,038 sec
    [junit] Testsuite: org.springframework.transaction.support.JtaTransactionManagerSerializationTests
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,038 sec

    [junit] Testcase: testSerializable took 0,016 sec
    [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 5,922 sec
    [junit] Testsuite: org.springframework.ui.jasperreports.JasperReportsUtilsTests
    [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 5,922 sec

    [junit] Testcase: testRenderAsCsvWithDataSource took 5,882 sec
    [junit] 	Caused an ERROR
    [junit] Unsupported major.minor version 49.0
    [junit] java.lang.UnsupportedClassVersionError: Unsupported major.minor version 49.0
    [junit] 	at java.lang.ClassLoader.defineClass0(Native Method)
    [junit] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:509)
    [junit] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:438)
    [junit] 	at net.sf.jasperreports.engine.util.JRClassLoader.loadClass(JRClassLoader.java:208)
    [junit] 	at net.sf.jasperreports.engine.util.JRClassLoader.loadClassFromBytes(JRClassLoader.java:123)
    [junit] 	at net.sf.jasperreports.engine.design.JRAbstractJavaCompiler.loadCalculator(JRAbstractJavaCompiler.java:63)
    [junit] 	at net.sf.jasperreports.engine.design.JRDefaultCompiler.loadCalculator(JRDefaultCompiler.java:156)
    [junit] 	at net.sf.jasperreports.engine.fill.JRBaseFiller.<init>(JRBaseFiller.java:327)
    [junit] 	at net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:83)
    [junit] 	at net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:75)
    [junit] 	at net.sf.jasperreports.engine.fill.JRFiller.fillReport(JRFiller.java:108)
    [junit] 	at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:429)
    [junit] 	at org.springframework.ui.jasperreports.JasperReportsUtils.renderAsCsv(JasperReportsUtils.java:127)
    [junit] 	at org.springframework.ui.jasperreports.JasperReportsUtilsTests.testRenderAsCsvWithDataSource(JasperReportsUtilsTests.java:55)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] FAILED BUILD: x86-solaris1 (last 30 lines included)

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

1116744981
FAILED
    [junit] Testcase: testCannotCreateTransaction took 0,007 sec
    [junit] Testcase: testCannotCommitTransaction took 0,002 sec
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,05 sec
    [junit] Testsuite: org.springframework.transaction.support.JtaTransactionManagerSerializationTests
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,05 sec

    [junit] Testcase: testSerializable took 0,011 sec
    [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 5,344 sec
    [junit] Testsuite: org.springframework.ui.jasperreports.JasperReportsUtilsTests
    [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 5,344 sec

    [junit] Testcase: testRenderAsCsvWithDataSource took 5,258 sec
    [junit] 	Caused an ERROR
    [junit] Unsupported major.minor version 49.0
    [junit] java.lang.UnsupportedClassVersionError: Unsupported major.minor version 49.0
    [junit] 	at java.lang.ClassLoader.defineClass0(Native Method)
    [junit] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
    [junit] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:431)
    [junit] 	at net.sf.jasperreports.engine.util.JRClassLoader.loadClass(JRClassLoader.java:208)
    [junit] 	at net.sf.jasperreports.engine.util.JRClassLoader.loadClassFromBytes(JRClassLoader.java:123)
    [junit] 	at net.sf.jasperreports.engine.design.JRAbstractJavaCompiler.loadCalculator(JRAbstractJavaCompiler.java:63)
    [junit] 	at net.sf.jasperreports.engine.design.JRDefaultCompiler.loadCalculator(JRDefaultCompiler.java:156)
    [junit] 	at net.sf.jasperreports.engine.fill.JRBaseFiller.<init>(JRBaseFiller.java:327)
    [junit] 	at net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:83)
    [junit] 	at net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:75)
    [junit] 	at net.sf.jasperreports.engine.fill.JRFiller.fillReport(JRFiller.java:108)
    [junit] 	at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:429)
    [junit] 	at org.springframework.ui.jasperreports.JasperReportsUtils.renderAsCsv(JasperReportsUtils.java:127)
    [junit] 	at org.springframework.ui.jasperreports.JasperReportsUtilsTests.testRenderAsCsvWithDataSource(JasperReportsUtilsTests.java:55)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] FAILED BUILD: sparc-solaris2 (last 30 lines included)

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

1116742097
FAILED
    [junit] Testcase: testCannotCreateTransaction took 0,013 sec
    [junit] Testcase: testCannotCommitTransaction took 0,003 sec
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,036 sec
    [junit] Testsuite: org.springframework.transaction.support.JtaTransactionManagerSerializationTests
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,036 sec

    [junit] Testcase: testSerializable took 0,015 sec
    [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 5,957 sec
    [junit] Testsuite: org.springframework.ui.jasperreports.JasperReportsUtilsTests
    [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 5,957 sec

    [junit] Testcase: testRenderAsCsvWithDataSource took 5,913 sec
    [junit] 	Caused an ERROR
    [junit] Unsupported major.minor version 49.0
    [junit] java.lang.UnsupportedClassVersionError: Unsupported major.minor version 49.0
    [junit] 	at java.lang.ClassLoader.defineClass0(Native Method)
    [junit] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:509)
    [junit] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:438)
    [junit] 	at net.sf.jasperreports.engine.util.JRClassLoader.loadClass(JRClassLoader.java:208)
    [junit] 	at net.sf.jasperreports.engine.util.JRClassLoader.loadClassFromBytes(JRClassLoader.java:123)
    [junit] 	at net.sf.jasperreports.engine.design.JRAbstractJavaCompiler.loadCalculator(JRAbstractJavaCompiler.java:63)
    [junit] 	at net.sf.jasperreports.engine.design.JRDefaultCompiler.loadCalculator(JRDefaultCompiler.java:156)
    [junit] 	at net.sf.jasperreports.engine.fill.JRBaseFiller.<init>(JRBaseFiller.java:327)
    [junit] 	at net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:83)
    [junit] 	at net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:75)
    [junit] 	at net.sf.jasperreports.engine.fill.JRFiller.fillReport(JRFiller.java:108)
    [junit] 	at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:429)
    [junit] 	at org.springframework.ui.jasperreports.JasperReportsUtils.renderAsCsv(JasperReportsUtils.java:127)
    [junit] 	at org.springframework.ui.jasperreports.JasperReportsUtilsTests.testRenderAsCsvWithDataSource(JasperReportsUtilsTests.java:55)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] FAILED BUILD: ppc-osx2 (last 30 lines included)

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

1116738336
FAILED
    [junit] Testcase: testCannotCommitTransaction took 0,002 sec
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,043 sec
    [junit] Testsuite: org.springframework.transaction.support.JtaTransactionManagerSerializationTests
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,043 sec

    [junit] Testcase: testSerializable took 0,008 sec
    [junit] 2005-05-22 05:54:25.455 java[29022] Warning: Font LucidaSans-TypewriterBold claims fixed-pitch with 0 max advance!
    [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 8,104 sec
    [junit] Testsuite: org.springframework.ui.jasperreports.JasperReportsUtilsTests
    [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 8,104 sec

    [junit] Testcase: testRenderAsCsvWithDataSource took 8,042 sec
    [junit] 	Caused an ERROR
    [junit] Unsupported major.minor version 49.0
    [junit] java.lang.UnsupportedClassVersionError: Unsupported major.minor version 49.0
    [junit] 	at java.lang.ClassLoader.defineClass0(Native Method)
    [junit] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:502)
    [junit] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:431)
    [junit] 	at net.sf.jasperreports.engine.util.JRClassLoader.loadClass(JRClassLoader.java:208)
    [junit] 	at net.sf.jasperreports.engine.util.JRClassLoader.loadClassFromBytes(JRClassLoader.java:123)
    [junit] 	at net.sf.jasperreports.engine.design.JRAbstractJavaCompiler.loadCalculator(JRAbstractJavaCompiler.java:63)
    [junit] 	at net.sf.jasperreports.engine.design.JRDefaultCompiler.loadCalculator(JRDefaultCompiler.java:156)
    [junit] 	at net.sf.jasperreports.engine.fill.JRBaseFiller.<init>(JRBaseFiller.java:327)
    [junit] 	at net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:83)
    [junit] 	at net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:75)
    [junit] 	at net.sf.jasperreports.engine.fill.JRFiller.fillReport(JRFiller.java:108)
    [junit] 	at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:429)
    [junit] 	at org.springframework.ui.jasperreports.JasperReportsUtils.renderAsCsv(JasperReportsUtils.java:127)
    [junit] 	at org.springframework.ui.jasperreports.JasperReportsUtilsTests.testRenderAsCsvWithDataSource(JasperReportsUtilsTests.java:55)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

[Springframework-developer] FAILED BUILD: x86-linux2 (last 30 lines included)

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

1116726978
FAILED
    [junit] Testcase: testCannotCreateTransaction took 0,006 sec
    [junit] Testcase: testCannotCommitTransaction took 0,002 sec
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,019 sec
    [junit] Testsuite: org.springframework.transaction.support.JtaTransactionManagerSerializationTests
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,019 sec

    [junit] Testcase: testSerializable took 0,009 sec
    [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1,175 sec
    [junit] Testsuite: org.springframework.ui.jasperreports.JasperReportsUtilsTests
    [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1,175 sec

    [junit] Testcase: testRenderAsCsvWithDataSource took 1,14 sec
    [junit] 	Caused an ERROR
    [junit] Unsupported major.minor version 49.0
    [junit] java.lang.UnsupportedClassVersionError: Unsupported major.minor version 49.0
    [junit] 	at java.lang.ClassLoader.defineClass0(Native Method)
    [junit] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
    [junit] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:448)
    [junit] 	at net.sf.jasperreports.engine.util.JRClassLoader.loadClass(JRClassLoader.java:208)
    [junit] 	at net.sf.jasperreports.engine.util.JRClassLoader.loadClassFromBytes(JRClassLoader.java:123)
    [junit] 	at net.sf.jasperreports.engine.design.JRAbstractJavaCompiler.loadCalculator(JRAbstractJavaCompiler.java:63)
    [junit] 	at net.sf.jasperreports.engine.design.JRDefaultCompiler.loadCalculator(JRDefaultCompiler.java:156)
    [junit] 	at net.sf.jasperreports.engine.fill.JRBaseFiller.<init>(JRBaseFiller.java:327)
    [junit] 	at net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:83)
    [junit] 	at net.sf.jasperreports.engine.fill.JRVerticalFiller.<init>(JRVerticalFiller.java:75)
    [junit] 	at net.sf.jasperreports.engine.fill.JRFiller.fillReport(JRFiller.java:108)
    [junit] 	at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:429)
    [junit] 	at org.springframework.ui.jasperreports.JasperReportsUtils.renderAsCsv(JasperReportsUtils.java:127)
    [junit] 	at org.springframework.ui.jasperreports.JasperReportsUtilsTests.testRenderAsCsvWithDataSource(JasperReportsUtilsTests.java:55)


This is an automated mail from one of the SF Compile Farm machines.  
The machine name noted in the subject encountered a failure building
or running the Spring test suite.  The last few lines of the output
were included for info.

NB: No further mail will be sent from this machine until a
manual reset occurs on the cf-shell machine, although builds will
continue as scheduled.

See http://springframework.sourceforge.net/test/ for further
information.

Re: [Springframework-developer] Spring 1.2 Spring JTA tx timeout, tx rolls back, but no exception thrown (another race condition)

[Dave B. <dba...@on...>]

Hi Juergen,

Thanks for checking into this. Does look a little ugly. Hopefully you'll 
find a way to tell the difference between the two different rollback 
situations (or to inquire if in fact a timeout has occurred). Currently 
this is a show-stopper for me. Although this type of timeout won't 
happen frequently, it will happen, and the consequences will be a little 
difficult to track down because of the lack of an exception.

Thanks again for your help,
Dave

Juergen Hoeller wrote:

>Good point - thanks for reporting this! JTA implementations seem to mark
>transaction as rollback-only when they have timed out, without further
>indication. So unless you attempt an actual resource operation after the
>timeout, there is no guarantee than an exception gets thrown before commit.
>
>If Spring discovers a rollback-only status, it assumes that the application
>has set the transaction to rollback-only and triggers a silent rollback.
>This will usually happen when TransactionStatus.setRollbackOnly() has been
>called, instead of configuring a rollback rule, with an application-level
>exception getting thrown.
>
>In the case of a JTA timeout, the rollback-only marker comes from the JTA
>subsystem, though. Spring effectively misinterprets that marker as driven by
>the application, which leads to an inappropriate silent reaction. I'll fix
>that for Spring 1.2.1, although it's unfortunately not that trivial for the
>general case.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Dave Ballard
>Sent: Friday, May 20, 2005 10:44 PM
>To: spr...@li...
>Subject: [Springframework-developer] Spring 1.2 Spring JTA tx timeout,
>tx rolls back, but no exception thrown (another race condition)
>
>
>Hi Juergen,
>
>Using unpatched Spring 1.2 on WebLogic 6.1. I've defined a
>Spring-managed service bean, with the following transaction manager and
>transaction interceptor beans:
>
>  <bean id="MyTransactionManager"
>class="org.springframework.transaction.jta.JtaTransactionManager">
>    <property
>name="transactionManagerName"><value>java:comp/UserTransaction</value></prop
>erty>
>  </bean>
>
>  <bean id="MyTransactionInterceptor"
>class="org.springframework.transaction.interceptor.TransactionInterceptor">
>    <property name="transactionManager"><ref
>bean="MyTransactionManager"/></property>
>    <property name="transactionAttributeSource">
>      <value>
>        PaymentService.commit=PROPAGATION_REQUIRED,-Exception
>      </value>
>    </property>
>  </bean>
>
>The transactional demarcation causes a commit when the method succeeds,
>and causes a rollback when an exception is thrown (and throws the
>exception), as expected. However, if I introduce a 40 second sleep in
>the method, the transaction rolls back as expected, but sometimes no
>exception is thrown. In the case where no exception is thrown, I can see
>in the Spring log:
>
> WARN 14:45:03,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (EjbUtils.java:626) - START SLEEP 40:
>PaymentServiceImpl.commit() 40 seconds......
> WARN 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (EjbUtils.java:633) - DONE  SLEEP 40:
>PaymentServiceImpl.commit() 40 seconds......
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (TransactionAspectSupport.java:258) - Invoking commit for
>transaction on PaymentService.commit
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (AbstractPlatformTransactionManager.java:382) -
>Transactional code has requested rollback
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (AbstractPlatformTransactionManager.java:542) - Triggering
>beforeCompletion synchronization
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (TransactionSynchronizationManager.java:177) - Removed
>value [org.springframework.orm.hibernate.SessionHolder@57f820] for key
>[net.sf.hibernate.impl.SessionFactoryImpl@39569e] from thread
>[ExecuteThread: '30' for queue: 'default']
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (SessionFactoryUtils.java:730) - Closing Hibernate Session
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (AbstractPlatformTransactionManager.java:463) - Initiating
>transaction rollback
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (JtaTransactionManager.java:719) - Rolling back JTA transaction
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (AbstractPlatformTransactionManager.java:572) - Triggering
>afterCompletion synchronization
>DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (TransactionSynchronizationManager.java:252) - Clearing
>transaction synchronization
> INFO 14:45:43,171 [ExecuteThread: '30' for queue: 'default']
>[edemo_acme] (PaymentCommit.java:167) - PERFORMANCE END   PaymentCommit
>
>This is an intermittent problem that occurs in both 1.1.5 and 1.2. I run
>the same test over and over, and while it always rolls back, it only
>sometimes throws an exception. In the case where it does throw an
>exception, the log is different:
>
> WARN 15:18:54,109 [ExecuteThread: '31' for queue: 'default']
>[edemo_acme] (EjbUtils.java:626) - START SLEEP 40:
>PaymentServiceImpl.commit() 40 seconds......
> WARN 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>[edemo_acme] (EjbUtils.java:633) - DONE  SLEEP 40:
>PaymentServiceImpl.commit() 40 seconds......
>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>[edemo_acme] (TransactionAspectSupport.java:241) - Invoking commit for
>transaction on method 'commit' in class [PaymentService]
>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>[edemo_acme] (AbstractPlatformTransactionManager.java:523) - Triggering
>beforeCommit synchronization
>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>[edemo_acme] (SessionFactoryUtils.java:809) - Flushing Hibernate session
>on transaction synchronization
>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>[edemo_acme] (SQLErrorCodeSQLExceptionTranslator.java:225) - Unable to
>translate SQLException with errorCode '0', will now try the fallback
>translator
>DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
>[edemo_acme] (SQLStateSQLExceptionTranslator.java:74) - Translating
>SQLException with SQLState 'null' and errorCode '0' and message [The
>transaction is no longer active (status = Rolled back.
>[Reason=weblogic.transaction.internal.TimedOutException: Transaction
>timed out after 28 seconds
>[snip]
>
>This appears to be another race condition. In the case where the
>exception is thrown, the transaction has not yet been flagged as
>rollback-only. The code proceeds to attempt a hibernate flush(), and
>this causes a SQLException(TimedOutException) to be thrown.
>
>In the first case where no exception is thrown, the transaction has
>already been flagged rollback-only, so the code never calls hibernate
>flush, and simply returns w/o an exception after rolling back the tx.
>
>This is a pretty serious problem for my application because the calling
>code has no idea that the transaction rolled back.
>
>Thanks,
>Dave
>
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

[Springframework-developer] spring build.266 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050522001710Lbuild.266

Re: [Springframework-developer] Spring 1.2 Spring JTA tx timeout, tx rolls back, but no exception thrown (another race condition)

[Juergen H. <ju...@in...>]

Good point - thanks for reporting this! JTA implementations seem to mark
transaction as rollback-only when they have timed out, without further
indication. So unless you attempt an actual resource operation after the
timeout, there is no guarantee than an exception gets thrown before commit.

If Spring discovers a rollback-only status, it assumes that the application
has set the transaction to rollback-only and triggers a silent rollback.
This will usually happen when TransactionStatus.setRollbackOnly() has been
called, instead of configuring a rollback rule, with an application-level
exception getting thrown.

In the case of a JTA timeout, the rollback-only marker comes from the JTA
subsystem, though. Spring effectively misinterprets that marker as driven by
the application, which leads to an inappropriate silent reaction. I'll fix
that for Spring 1.2.1, although it's unfortunately not that trivial for the
general case.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Dave Ballard
Sent: Friday, May 20, 2005 10:44 PM
To: spr...@li...
Subject: [Springframework-developer] Spring 1.2 Spring JTA tx timeout,
tx rolls back, but no exception thrown (another race condition)


Hi Juergen,

Using unpatched Spring 1.2 on WebLogic 6.1. I've defined a
Spring-managed service bean, with the following transaction manager and
transaction interceptor beans:

  <bean id="MyTransactionManager"
class="org.springframework.transaction.jta.JtaTransactionManager">
    <property
name="transactionManagerName"><value>java:comp/UserTransaction</value></prop
erty>
  </bean>

  <bean id="MyTransactionInterceptor"
class="org.springframework.transaction.interceptor.TransactionInterceptor">
    <property name="transactionManager"><ref
bean="MyTransactionManager"/></property>
    <property name="transactionAttributeSource">
      <value>
        PaymentService.commit=PROPAGATION_REQUIRED,-Exception
      </value>
    </property>
  </bean>

The transactional demarcation causes a commit when the method succeeds,
and causes a rollback when an exception is thrown (and throws the
exception), as expected. However, if I introduce a 40 second sleep in
the method, the transaction rolls back as expected, but sometimes no
exception is thrown. In the case where no exception is thrown, I can see
in the Spring log:

 WARN 14:45:03,156 [ExecuteThread: '30' for queue: 'default']
[edemo_acme] (EjbUtils.java:626) - START SLEEP 40:
PaymentServiceImpl.commit() 40 seconds......
 WARN 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
[edemo_acme] (EjbUtils.java:633) - DONE  SLEEP 40:
PaymentServiceImpl.commit() 40 seconds......
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
[edemo_acme] (TransactionAspectSupport.java:258) - Invoking commit for
transaction on PaymentService.commit
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
[edemo_acme] (AbstractPlatformTransactionManager.java:382) -
Transactional code has requested rollback
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
[edemo_acme] (AbstractPlatformTransactionManager.java:542) - Triggering
beforeCompletion synchronization
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
[edemo_acme] (TransactionSynchronizationManager.java:177) - Removed
value [org.springframework.orm.hibernate.SessionHolder@57f820] for key
[net.sf.hibernate.impl.SessionFactoryImpl@39569e] from thread
[ExecuteThread: '30' for queue: 'default']
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
[edemo_acme] (SessionFactoryUtils.java:730) - Closing Hibernate Session
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
[edemo_acme] (AbstractPlatformTransactionManager.java:463) - Initiating
transaction rollback
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
[edemo_acme] (JtaTransactionManager.java:719) - Rolling back JTA transaction
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
[edemo_acme] (AbstractPlatformTransactionManager.java:572) - Triggering
afterCompletion synchronization
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default']
[edemo_acme] (TransactionSynchronizationManager.java:252) - Clearing
transaction synchronization
 INFO 14:45:43,171 [ExecuteThread: '30' for queue: 'default']
[edemo_acme] (PaymentCommit.java:167) - PERFORMANCE END   PaymentCommit

This is an intermittent problem that occurs in both 1.1.5 and 1.2. I run
the same test over and over, and while it always rolls back, it only
sometimes throws an exception. In the case where it does throw an
exception, the log is different:

 WARN 15:18:54,109 [ExecuteThread: '31' for queue: 'default']
[edemo_acme] (EjbUtils.java:626) - START SLEEP 40:
PaymentServiceImpl.commit() 40 seconds......
 WARN 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
[edemo_acme] (EjbUtils.java:633) - DONE  SLEEP 40:
PaymentServiceImpl.commit() 40 seconds......
DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
[edemo_acme] (TransactionAspectSupport.java:241) - Invoking commit for
transaction on method 'commit' in class [PaymentService]
DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
[edemo_acme] (AbstractPlatformTransactionManager.java:523) - Triggering
beforeCommit synchronization
DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
[edemo_acme] (SessionFactoryUtils.java:809) - Flushing Hibernate session
on transaction synchronization
DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
[edemo_acme] (SQLErrorCodeSQLExceptionTranslator.java:225) - Unable to
translate SQLException with errorCode '0', will now try the fallback
translator
DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default']
[edemo_acme] (SQLStateSQLExceptionTranslator.java:74) - Translating
SQLException with SQLState 'null' and errorCode '0' and message [The
transaction is no longer active (status = Rolled back.
[Reason=weblogic.transaction.internal.TimedOutException: Transaction
timed out after 28 seconds
[snip]

This appears to be another race condition. In the case where the
exception is thrown, the transaction has not yet been flagged as
rollback-only. The code proceeds to attempt a hibernate flush(), and
this causes a SQLException(TimedOutException) to be thrown.

In the first case where no exception is thrown, the transaction has
already been flagged rollback-only, so the code never calls hibernate
flush, and simply returns w/o an exception after rolling back the tx.

This is a pretty serious problem for my application because the calling
code has no idea that the transaction rolled back.

Thanks,
Dave






-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Changing the From Address on JIRA mails

[Rob H. <rob...@in...>]

Changed to ji...@sp....


Colin Sampaleanu wrote:
> Rob Harrop wrote:
> 
>> Does anyone object to me changing the from address of the Spring JIRA 
>> mails? This will make it easier to filter the mails.
>>
>> Rob
> 
> 
> That makes sense
> 

-- 
Rob Harrop
Interface21 - Spring Services from the Source
http://www.springframework.com

Re: [Springframework-developer] Changing the From Address on JIRA mails

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

Rob Harrop wrote:

> Does anyone object to me changing the from address of the Spring JIRA 
> mails? This will make it easier to filter the mails.
>
> Rob

That makes sense

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

[Springframework-developer] Changing the From Address on JIRA mails

[Rob H. <rob...@in...>]

Does anyone object to me changing the from address of the Spring JIRA 
mails? This will make it easier to filter the mails.

Rob

[Springframework-developer] velocity tool, import for spring

[Achmad A. R. <a.a...@gm...>]

Hi guys, is there any idea how to integrate velocity-view-tool especially=
=20
$import , into springMacroRequestContext ?=20
 thnx.

[Springframework-developer] spring build.265 Build Fixed

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050521001627Lbuild.265

[Springframework-developer] Spring 1.2 Spring JTA tx timeout, tx rolls back, but no exception thrown (another race condition)

[Dave B. <dba...@on...>]

Hi Juergen,

Using unpatched Spring 1.2 on WebLogic 6.1. I've defined a 
Spring-managed service bean, with the following transaction manager and 
transaction interceptor beans:

  <bean id="MyTransactionManager" 
class="org.springframework.transaction.jta.JtaTransactionManager">
    <property 
name="transactionManagerName"><value>java:comp/UserTransaction</value></property>
  </bean>

  <bean id="MyTransactionInterceptor" 
class="org.springframework.transaction.interceptor.TransactionInterceptor">
    <property name="transactionManager"><ref 
bean="MyTransactionManager"/></property>
    <property name="transactionAttributeSource">
      <value>
        PaymentService.commit=PROPAGATION_REQUIRED,-Exception
      </value>
    </property>
  </bean>

The transactional demarcation causes a commit when the method succeeds, 
and causes a rollback when an exception is thrown (and throws the 
exception), as expected. However, if I introduce a 40 second sleep in 
the method, the transaction rolls back as expected, but sometimes no 
exception is thrown. In the case where no exception is thrown, I can see 
in the Spring log:

 WARN 14:45:03,156 [ExecuteThread: '30' for queue: 'default'] 
[edemo_acme] (EjbUtils.java:626) - START SLEEP 40: 
PaymentServiceImpl.commit() 40 seconds......
 WARN 14:45:43,156 [ExecuteThread: '30' for queue: 'default'] 
[edemo_acme] (EjbUtils.java:633) - DONE  SLEEP 40: 
PaymentServiceImpl.commit() 40 seconds......
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default'] 
[edemo_acme] (TransactionAspectSupport.java:258) - Invoking commit for 
transaction on PaymentService.commit
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default'] 
[edemo_acme] (AbstractPlatformTransactionManager.java:382) - 
Transactional code has requested rollback
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default'] 
[edemo_acme] (AbstractPlatformTransactionManager.java:542) - Triggering 
beforeCompletion synchronization
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default'] 
[edemo_acme] (TransactionSynchronizationManager.java:177) - Removed 
value [org.springframework.orm.hibernate.SessionHolder@57f820] for key 
[net.sf.hibernate.impl.SessionFactoryImpl@39569e] from thread 
[ExecuteThread: '30' for queue: 'default']
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default'] 
[edemo_acme] (SessionFactoryUtils.java:730) - Closing Hibernate Session
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default'] 
[edemo_acme] (AbstractPlatformTransactionManager.java:463) - Initiating 
transaction rollback
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default'] 
[edemo_acme] (JtaTransactionManager.java:719) - Rolling back JTA transaction
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default'] 
[edemo_acme] (AbstractPlatformTransactionManager.java:572) - Triggering 
afterCompletion synchronization
DEBUG 14:45:43,156 [ExecuteThread: '30' for queue: 'default'] 
[edemo_acme] (TransactionSynchronizationManager.java:252) - Clearing 
transaction synchronization
 INFO 14:45:43,171 [ExecuteThread: '30' for queue: 'default'] 
[edemo_acme] (PaymentCommit.java:167) - PERFORMANCE END   PaymentCommit

This is an intermittent problem that occurs in both 1.1.5 and 1.2. I run 
the same test over and over, and while it always rolls back, it only 
sometimes throws an exception. In the case where it does throw an 
exception, the log is different:

 WARN 15:18:54,109 [ExecuteThread: '31' for queue: 'default'] 
[edemo_acme] (EjbUtils.java:626) - START SLEEP 40: 
PaymentServiceImpl.commit() 40 seconds......
 WARN 15:19:34,109 [ExecuteThread: '31' for queue: 'default'] 
[edemo_acme] (EjbUtils.java:633) - DONE  SLEEP 40: 
PaymentServiceImpl.commit() 40 seconds......
DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default'] 
[edemo_acme] (TransactionAspectSupport.java:241) - Invoking commit for 
transaction on method 'commit' in class [PaymentService]
DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default'] 
[edemo_acme] (AbstractPlatformTransactionManager.java:523) - Triggering 
beforeCommit synchronization
DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default'] 
[edemo_acme] (SessionFactoryUtils.java:809) - Flushing Hibernate session 
on transaction synchronization
DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default'] 
[edemo_acme] (SQLErrorCodeSQLExceptionTranslator.java:225) - Unable to 
translate SQLException with errorCode '0', will now try the fallback 
translator
DEBUG 15:19:34,109 [ExecuteThread: '31' for queue: 'default'] 
[edemo_acme] (SQLStateSQLExceptionTranslator.java:74) - Translating 
SQLException with SQLState 'null' and errorCode '0' and message [The 
transaction is no longer active (status = Rolled back. 
[Reason=weblogic.transaction.internal.TimedOutException: Transaction 
timed out after 28 seconds
[snip]

This appears to be another race condition. In the case where the 
exception is thrown, the transaction has not yet been flagged as 
rollback-only. The code proceeds to attempt a hibernate flush(), and 
this causes a SQLException(TimedOutException) to be thrown.

In the first case where no exception is thrown, the transaction has 
already been flagged rollback-only, so the code never calls hibernate 
flush, and simply returns w/o an exception after rolling back the tx.

This is a pretty serious problem for my application because the calling 
code has no idea that the transaction rolled back.

Thanks,
Dave

Re: [Springframework-developer] Race condition with transaction synchronization?

[Dave B. <dba...@on...>]

Hi Juergen,

I have patched my Spring 1.2 with your updated SessionFactoryUtils and 
SessionHolder, and switched over to JtaTransactionManager. Seems to fix 
this problem.

Thanks for your help,
Dave

PS: I found another race condition with timeouts. I will post in a 
separate email.

Juergen Hoeller wrote:

>You don't need to use WebLogicJtaTransactionManager unless you intend to
>leverage WebLogic-specific (7.0+) JTA extensions. A plain
>JtaTransactionManager should be sufficient for typical usage. If you need
>transaction suspension, specify the corresponding "transactionManagerName"
>(see JtaTransactionManager's javadoc): this will enable
>PROPAGATION_REQUIRES_NEW and PROPAGATION_NOT_SUPPORTED.
>
>You could try to patch 1.1.5 accordingly, but I would recommend to use an
>upcoming nightly build or wait for 1.2.1 (which is scheduled for next
>Friday).
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Dave Ballard
>Sent: Friday, May 20, 2005 7:20 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Race condition with transaction
>synchronization?
>
>
>Hi Juergen,
>
>Thanks for looking into this and providing an insightful description of
>the problem. For me, this mix of EJB CMT and Spring tx demarcation is
>only a temporary situation as I transition away from EJB. I've got a
>service methods that are called from both the web tier (need Spring to
>start a transaction) and from a SLSB (EJB CMT starts transaction).
>
>My problem now is that Spring 1.2's WebLogicJtaTransactionManager is not
>compatible with WebLogic 6.1
>(org.springframework.transaction.TransactionSystemException: Could not
>initialize WebLogicJtaTransactionManager because WebLogic API classes
>are not available; nested exception is java.lang.ClassNotFoundException:
>weblogic.transaction.UserTransaction.).
>
>Do you think that your fix below is something that could be patched into
>1.1.5? I'll do it, but I don't want to waste my time if you don't think
>that it is a good idea.
>
>Thanks,
>Dave
>
>Juergen Hoeller wrote:
>
>  
>
>>Hi Dave,
>>
>>I've just verified that your scenario can indeed lead to broken cleanup:
>>
>>If the rollback gets triggered from some other thread (i.e. not the thread
>>that created the transaction), the Hibernate SessionHolder cannot get
>>removed from the original thread. That is actually already expected, as it
>>can also happen in case of remote transaction propagation: Spring will
>>simply remove the current Hibernate Session from the SessionHolder in this
>>case, and reuse the SessionHolder when another transaction gets executed on
>>that thread.
>>
>>However, the above only works with direct JTA Session synchronization only.
>>If Spring transaction synchronization is involved too (that is, if
>>transactions get initiated from either EJB CMT or Spring transaction
>>demarcation, not just from EJB CMT), an IllegalStateException will be
>>    
>>
>thrown
>  
>
>>whenever a thread with such an empty SessionHolder is supposed to execute a
>>Spring-driven transaction. This is straightforward to reproduce in a test
>>case.
>>
>>I've just fixed this issue for both Hibernate 2.1 and Hibernate3, to be
>>committed today. The fix should be available in the next nightly build, and
>>will be released in Spring 1.2.1.
>>
>>Note that it's generally recommended to use *either* EJB CMT *or*
>>Spring-driven transactions. Spring's Session synchronization for Hibernate
>>will work nicely with EJB CMT only, without any Spring transaction
>>demarcation involved. Mixing both is nevertheless valid, therefore the
>>    
>>
>above
>  
>
>>fix is necessary.
>>
>>Thanks for reporting this!
>>
>>Juergen
>>
>>
>>-----Original Message-----
>>From: spr...@li...
>>[mailto:spr...@li...]On Behalf
>>Of Dave Ballard
>>Sent: Wednesday, May 18, 2005 10:41 PM
>>To: spr...@li...
>>Subject: Re: [Springframework-developer] Race condition with transaction
>>synchronization?
>>
>>
>>Hello,
>>
>>Sorry to respond to my own post, but if there's someone out there that
>>is familiar with SessionFactoryUtils, I would appreciate a little of
>>your time to discuss this issue. This appears to be a bug in the JTA
>>session synchronization code for hibernate.
>>
>>Thanks,
>>Dave
>>
>>Dave Ballard wrote:
>>
>>
>>
>>    
>>
>>>Hello,
>>>
>>>I posted this on the forums, but costin and Rod suggested that I post
>>>it here.
>>>
>>>I'm using Spring Framework 1.1.5 with Hibernate on WebLogic Server
>>>6.1. I'm testing timeout scenarios, and I've run into an issue I need
>>>some help with. I'm slowly eliminating EJB's from my application, but
>>>I do have some legacy EJB code to deal with. In my scenario, my
>>>servlet is calling a SLSB, which in turn calls spring-managed
>>>transactional services. These transaction service join the CMT
>>>transaction created by the EJB container. I have:
>>>
>>>Code:
>>>
>>>1) A servlet calls SLSB with CMT.
>>>2) The SLSB calls SessionFactoryUtils.getSession(sessionFactory, true)
>>>-- This binds the hibernate session to the current thread
>>>3) The SLSB calls a spring-managed transactional service
>>>-- This bean uses the bound session as expected
>>>4) The SLSB calls another spring-managed transactional service
>>>-- This bean uses the bound session as expected
>>>5) The SLSB exits
>>>-- The TransactionSynchronizationManager unbinds the bound session as
>>>expected
>>>
>>>
>>>So the non-timeout scenario functions as expected. Now I introduce a
>>>timeout (by causing blocking in by database) prior to (3). With the
>>>timeout scenario, I encounter one of two results:
>>>
>>>Code:
>>>
>>>A) A spring HibernateJdbcException wrapping a weblogic
>>>TimedOutException as expected.
>>>B) An IllegalStateException Already value
>>>[org.springframework.orm.hibernate.SessionHolder@6f2304] for key
>>>[net.sf.hibernate.impl.SessionFactoryImpl@655ad0] bound to thread
>>>[ExecuteThread: '29' for queue: 'default']
>>>
>>>
>>>Whether I get (A) or (B) is seemingly random. I've created a
>>>diagnostic version of SessionFactoryUtils to see what is happening in
>>>more detail.
>>>In scenario (B), it looks like WebLogic's transaction manager is
>>>grabbing another thread from the pool and is invoking spring's
>>>JtaSessionSynchronization.afterCompletion() which is resulting in
>>>doClose() being called. I've added a dumpStack() in doClose(), and
>>>here is what I see. The line numbers will be a little off because of
>>>my diagnostic code:
>>>
>>>Code:
>>>
>>>java.lang.Exception: Stack trace
>>>      at java.lang.Thread.dumpStack(Thread.java:992)
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>org.springframework.orm.hibernate.SessionFactoryUtils.doClose(SessionFactor
>>    
>>
>y
>  
>
>>Utils.java:738)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>org.springframework.orm.hibernate.SessionFactoryUtils.closeSessionOrRegiste
>>    
>>
>r
>  
>
>>DeferredClose(SessionFactoryUtils.java:726)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>org.springframework.orm.hibernate.SessionFactoryUtils.access$300(SessionFac
>>    
>>
>t
>  
>
>>oryUtils.java:89)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>org.springframework.orm.hibernate.SessionFactoryUtils$SpringSessionSynchron
>>    
>>
>i
>  
>
>>zation.beforeCompletion(SessionFactoryUtils.java:867)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>org.springframework.orm.hibernate.SessionFactoryUtils$JtaSessionSynchroniza
>>    
>>
>t
>  
>
>>ion.afterCompletion(SessionFactoryUtils.java:978)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>weblogic.transaction.internal.ServerSCInfo.callAfterCompletions(ServerSCInf
>>    
>>
>o
>  
>
>>.java:464)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>weblogic.transaction.internal.ServerTransactionImpl.callAfterCompletions(Se
>>    
>>
>r
>  
>
>>verTransactionImpl.java:2139)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>weblogic.transaction.internal.ServerTransactionImpl.setRolledBack(ServerTra
>>    
>>
>n
>  
>
>>sactionImpl.java:2090)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>weblogic.transaction.internal.ServerTransactionImpl.globalRetryRollback(Ser
>>    
>>
>v
>  
>
>>erTransactionImpl.java:2188)DEBUG
>>
>>
>>    
>>
>>>18:19:23,000 [ExecuteThread: '34' for queue: 'default'] [edemo_acme]
>>>(Transacti
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>weblogic.transaction.internal.ServerTransactionImpl.globalRollback(ServerTr
>>    
>>
>a
>  
>
>>nsactionImpl.java:2080)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>weblogic.transaction.internal.TransactionImpl$1.execute(TransactionImpl.jav
>>    
>>
>a
>  
>
>>:1617)
>>
>>
>>    
>>
>>>      at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:159)
>>>      at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:140)
>>>
>>>
>>>Meanwhile, the original timeout thread, who is in the middle of
>>>calling getSession(), and hasn't yet encountered the weblogic
>>>TimedOutException,
>>>tries to bind the session holder to the thread, and fails:
>>>
>>>Code:
>>>
>>>ERROR 18:19:23,046 [ExecuteThread: '34' for queue: 'default']
>>>[edemo_acme] (TransactionAspectSupport.java:264) - Application
>>>exception overridden by rollback exception
>>>java.lang.IllegalStateException: Already value
>>>[org.springframework.orm.hibernate.SessionHolder@747db9] for key
>>>[net.sf.hibernate.impl.SessionFactoryImpl@606e55] bound to thread
>>>[ExecuteThread: '34' for queue: 'default']
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>org.springframework.transaction.support.TransactionSynchronizationManager.b
>>    
>>
>i
>  
>
>>ndResource(TransactionSynchronizationManager.java:147)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>org.springframework.orm.hibernate.SessionFactoryUtils.getSession(SessionFac
>>    
>>
>t
>  
>
>>oryUtils.java:346)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>org.springframework.orm.hibernate.SessionFactoryUtils.getSession(SessionFac
>>    
>>
>t
>  
>
>>oryUtils.java:266)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>org.springframework.orm.hibernate.SessionFactoryUtils.getSession(SessionFac
>>    
>>
>t
>  
>
>>oryUtils.java:223)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>org.springframework.orm.hibernate.HibernateInterceptor.invoke(HibernateInte
>>    
>>
>r
>  
>
>>ceptor.java:149)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Reflec
>>    
>>
>t
>  
>
>>iveMethodInvocation.java:144)
>>
>>
>>    
>>
>>>      at
>>>
>>>
>>>
>>>      
>>>
>>org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopPr
>>    
>>
>o
>  
>
>>xy.java:174)
>>
>>
>>    
>>
>>>      at $Proxy93.findContract(Unknown Source)
>>>      at
>>>mycode.ContractServiceImpl.findContract(ContractServiceImpl.java:59)
>>>      ...
>>>
>>>
>>>It's not clear to me who the culprit is here, not being that familiar
>>>with JTA and Spring. Perhaps the beforeCompletion() called by the
>>>weblogic transaction manager is not cleaning up properly? Any ideas?
>>>
>>>Thanks for your help,
>>>Dave
>>>
>>>
>>>-------------------------------------------------------
>>>This SF.Net email is sponsored by Oracle Space Sweepstakes
>>>Want to be the first software developer in space?
>>>Enter now for the Oracle Space Sweepstakes!
>>>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>>>_______________________________________________
>>>Springframework-developer mailing list
>>>Spr...@li...
>>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>>
>>>
>>>
>>>
>>>      
>>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by Oracle Space Sweepstakes
>>Want to be the first software developer in space?
>>Enter now for the Oracle Space Sweepstakes!
>>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by Oracle Space Sweepstakes
>>Want to be the first software developer in space?
>>Enter now for the Oracle Space Sweepstakes!
>>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>>
>>    
>>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>

RE: [Springframework-developer] Object Graph Assembler proposal feedback requested...

[Boyce, K. G. <Kei...@bc...>]

I am... Best thing since sliced bread :-) And I can't wait for Spring
IDE to make it look pretty for my managers....


  _____ =0D

	From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Keith Donald
	Sent: Friday, May 20, 2005 3:40 PM
	To: spr...@li...
	Subject: RE: [Springframework-developer] Object Graph Assembler
proposal feedback requested...
=0D
=0D

	Garry,

	=0D

	Yes I've been meaning to take a look at this. Just no time
yet....  It looks interesting.

	=0D

	Hope you're enjoying using SWF :-) Keith

	=0D

=0D
  _____ =0D


	From: spr...@li...
[mailto:spr...@li...] On Behalf
Of Boyce, Keith Garry
	Sent: Friday, May 20, 2005 1:31 PM
	To: Spr...@li...
	Subject: [Springframework-developer] Object Graph Assembler
proposal feedback requested...

	=0D

	Hi Keith and Juergen,=0D

	    A while ago I submitted a proposal in the forum for an
Object Graph Assembler and as of let I have received no feedback. I
wanted to make sure you guys understood my intent and what your thoughts
were on the implementation.
http://forum.springframework.org/viewtopic.php?t=3D5462
<http://forum.springframework.org/viewtopic.php?t=3D5462> .

	I submitted the code and created a JIRA at
http://opensource.atlassian.com/projects/spring/browse/SPR-945=0D

	BTW great presentation at
http://static.springframework.org/spring/presentations/2004/spring-intro
duction-to-lightweight-architecture/
<http://static.springframework.org/spring/presentations/2004/spring-intr
oduction-to-lightweight-architecture/> . It was an excellent delivery.

	=0D

	Thanks,=0D
	Garry=0D



This message is a PRIVATE communication.
If you are not the intended recipient, please do not read, copy,
or use it, and do not disclose it to others. Please notify the
sender of the delivery error by replying to this message, and then
delete it from your system. Thank you.