Hibernate Community • View topic - minimal spring + hibernate

View unanswered posts | View active topics

Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]

minimal spring + hibernate - transaction question

Page 1 of 2

[ 17 posts ]

Go to page 1, 2 Next

Previous topic | Next topic

Author

Message

tysonnorris

Post subject: minimal spring + hibernate - transaction question

Posted: Tue Dec 16, 2003 10:13 pm

Beginner

Joined: Tue Aug 26, 2003 6:24 pm
Posts: 45

Hi All-
I'm trying to use the HibernateTemplate from springframework as a simple hibernate API so that session handling is less complicated.

I'm not exatly sure how to get the HibernateTransactionManager or JTATransactionManager configured within my application so that the hibernate session is reused for multiple queries in the same thread. I'm not configuring a "spring application", just:
- initing Hibernate's SessionFactory using hibernate.properties
- calling Spring's TransactionSynchronizationManager.initSynchronization();

But it seems that init synchronization must be init'd for every request - is this correct? If so, do I need to modify spring's HibernateTemplate to perform this init with each call?

Sorry if this is confusing - I'm basically attempting to get hibernate session-reuse implemented as simple as possible, and the spring "template" system seems like its pretty close to what I want, I'm just missing something somewhere...

thanks for any info!
tyson

Top

mnickel

Post subject:

Posted: Wed Dec 17, 2003 12:32 am

Newbie

Joined: Wed Nov 12, 2003 11:16 am
Posts: 9

Would you please share your reasoning for not configuring the Hibernate SessionFactory through the Spring Framework.

My guess is that the Spring framework references objects that have been wired together through the applicationContext.xml file.

I'm thinking the the Spring framework is not re-using certain components because the transaction component was not initialized correctly.

Why is it that you are not wiring up the Hibernate SessionFactory through the applicationContext.xml file? The framework is quite good and can make use of the Apache Commons DB connection pooling.

Bottomline: if possible, I'd attempt to put more of your Hibernate stuff into the Spring framework. Let Spring take care of all the stuff from the bottom up through the DAO and instantiating some of your business objects. That way you can make use of the transactional support and not have to worry about these issues... Theoretically of course... :)

IMHO the additional overhead is worth it for not having to worry about tricky low level things...

Top

jhoeller

Post subject:

Posted: Wed Dec 17, 2003 4:29 am

Senior

Joined: Wed Aug 27, 2003 6:04 am
Posts: 161
Location: Linz, Austria

Let me clarify a couple of things here:

TransactionSynchronizationManager is an internal class that's used for thread binding and afterCompletion callbacks. You should never need to use that directly.

You can use HibernateTemplate and HibernateTransactionManager outside a Spring application context. What you need to do is demarcate transactions: Within a transaction, the same Hibernate Session will automatically be reused.

Manual transaction demarcation could look as follows. Within the try block, you can invoke any HibernateTemplate or SessionFactoryUtils operations: They will automatically participate in the surrounding transaction.

Code:

PlatformTransactionManager tm = new HibernateTransactionManager(sessionFactory);
TransactionDefinition td = new DefaultTransactionDefinition();
// optionally customize transaction definition here
TransactionStatus status = tm.getTransaction(td);
try {
  // invoke data access operations
}
catch (Exception ex) {  // catch your application exceptions here
  tm.rollback(status);
  throw ex;
}
tm.commit(status);

This is very similar to programmatic demarcation via JTA's UserTransaction: commit/rollback handling follows the same idiom. JTA doesn't provide any means to customize the transaction, though, and doesn't separate between manager and status.

Alternatively, you can use Spring's TransactionTemplate for easier programmatic demarcation. Note that you need to convert application-level checked exceptions within the callback code here: The callback is just allowed to throw unchecked exceptions.

Code:

PlatformTransactionManager tm = new HibernateTransactionManager(sessionFactory);
TransactionTemplate tt = new TransactionTemplate();
// optionally customize transaction template here
tt.execute(new TransactionCallback() {
  public Object doInTransaction(TransactionStatus status) {
    // invoke data access operations
  }
});

Of course, you're invited to use Spring's application context for wiring up, and possibly declarative transactions via TransactionProxyFactoryBean - but purely programmatic usage should be fine too!

Juergen

Top

tysonnorris

Post subject: rely on JTA for demarcation?

Posted: Wed Dec 17, 2003 4:55 pm

Beginner

Joined: Tue Aug 26, 2003 6:24 pm
Posts: 45

Hi Juergen -
thanks for your help!

I have the HibernateTransactionManager working outside a spring application context, as you've described above. Is there a way for me to automatically participate in exisitng JTA transactions?

For example, my current code looks something like:

Code:

//manually init UserTransaction:
InitialContext ctx = new InitialContext();
UserTransaction tx = (UserTransaction)  ctx.lookup("javax.transaction.UserTransaction");
tx.begin();

//init spring's HibernateTransactionManager:
PlatformTransactionManager tm = [a HibernateTransactionManager];
TransactionDefinition td = new DefaultTransactionDefinition();
TransactionStatus status = tm.getTransaction(td);

//do methodA() with the HibernateTemplate

//do methodB() with the HibernateTemplate

//commit the spring transaction
tm.commit(status)

//commit the JTA transaction
//tx.commit();

Obviously, I'm not paying attention to rollbacks etc at the moment.

Now, can I wrap up methodA() and methodB() to automatically participate in the JTA transaction? And have the hibernate session remain for the life of the transaction?

I think it would be possible to use JtaTransactionManager() to create/commit/rollback the JTA transaction (as mentioned in the docs - use JTA TransactionManager to create/manage JTA transactions using sprig), BUT, how can I use Hibernate's JTA participation and Spring's Hibernate SessionHolder without using Spring's JTA transaction management (i.e. use container JTA transaction, or none at all)?

thanks
tyson

Top

tysonnorris

Post subject: a related question...

Posted: Wed Dec 17, 2003 8:34 pm

Beginner

Joined: Tue Aug 26, 2003 6:24 pm
Posts: 45

Hi Juergen -

In my example above, I have one other issue:

Code:

//manually init UserTransaction: 
InitialContext ctx = new InitialContext(); 
UserTransaction tx = (UserTransaction)  ctx.lookup("javax.transaction.UserTransaction"); 
tx.begin(); 

//init spring's HibernateTransactionManager: 
PlatformTransactionManager tm = [a HibernateTransactionManager]; 
TransactionDefinition td = new DefaultTransactionDefinition(); 
TransactionStatus status = tm.getTransaction(td); 

//do methodA() with the HibernateTemplate 

//do methodB() with the HibernateTemplate 

//commit the spring transaction 
tm.commit(status) 

//commit the JTA transaction 
tx.commit();

If I generate a UserTransaction , and all works fine - single hibernate session that obtains the JTA transaction; session closed after both commits (spring commit and JTA commit).

However, if I remove the JTA transaction, as in:

Code:

//init spring's HibernateTransactionManager: 
PlatformTransactionManager tm = [a HibernateTransactionManager]; 
TransactionDefinition td = new DefaultTransactionDefinition(); 
TransactionStatus status = tm.getTransaction(td); 

//do methodA() with the HibernateTemplate 

//do methodB() with the HibernateTemplate 

//commit the spring transaction 
tm.commit(status) 

I get an exception during for the HibernateTransactionManager.cleanupAfterCompletion();
It is failing on the con.isReadOnly() method - some log data below.
This is running with an Oracle DataSource within WebLogic, btw.

thanks for any info
tyson

Code:

DEBUG|04:27:34.259|net.sf.hibernate.transaction.JTATransaction|Obtained UserTransaction
DEBUG|04:27:34.259|net.sf.hibernate.transaction.JTATransaction|beginning new transaction
DEBUG|04:27:34.259|org.springframework.orm.hibernate.HibernateTransactionManager|Triggering beforeCommit synch
ronization
DEBUG|04:27:34.259|org.springframework.orm.hibernate.HibernateTransactionManager|Triggering beforeCompletion s
ynchronization
DEBUG|04:27:34.259|org.springframework.orm.hibernate.HibernateTransactionManager|Initiating transaction commit

DEBUG|04:27:34.259|org.springframework.orm.hibernate.HibernateTransactionManager|Committing Hibernate transact
ion
DEBUG|04:27:34.259|net.sf.hibernate.transaction.JTATransaction|commit
DEBUG|04:27:34.259|org.springframework.orm.hibernate.HibernateTransactionManager|Triggering afterCompletion sy
nchronization
WARN |04:27:34.274|org.springframework.orm.hibernate.HibernateTransactionManager|Could not reset JDBC connecti
on of Hibernate session
java.sql.SQLException: The transaction is no longer active - status: 'Committed'. No further JDBC access is al
lowed within this transaction.
        at weblogic.jdbc.wrapper.JTSConnection.checkIfRolledBack(JTSConnection.java:118)
        at weblogic.jdbc.wrapper.JTSConnection.checkConnection(JTSConnection.java:127)
        at weblogic.jdbc.wrapper.Connection.preInvocationHandler(Connection.java:67)
        at weblogic.jdbc.wrapper.JTSConnection_oracle_jdbc_driver_OracleConnection.isReadOnly(Unknown Source)
        at org.springframework.orm.hibernate.HibernateTransactionManager.cleanupAfterCompletion(HibernateTrans
actionManager.java:351)
        at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformT
ransactionManager.java:178)

Top

jhoeller

Post subject:

Posted: Thu Dec 18, 2003 2:18 pm

Senior

Joined: Wed Aug 27, 2003 6:04 am
Posts: 161
Location: Linz, Austria

Never mind the "isReadOnly" message - it's just a warning that the Connection could not be reset to its original state (many application servers don't complain here). We should probably reduce the logging level here. The only difference when you omit the surrounding UserTransaction is that HibernateTransactionManager will use its own JTA transaction instead of participating in an existing one.

You're right that for Hibernate 2.0.x, you need to do explicit Hibernate transaction management to properly participate in JTA transactions including proper cache callbacks. In the Spring case, this means using HibernateTransactionManager with JTATransaction on the Hibernate side: If a JTA transaction already exists, it will participate in it; else, it will execute in its own JTA transaction.

Hibernate 2.1 will automatically detect an existing JTA transaction and register with it. Therefore, you don't need to do explicit Hibernate transaction management respectively use HibernateTransactionManager in addition to JTA. However, you won't reuse a Session instance this way. Fortunately, the above Hibernate 2.0 strategy will still work, as HibernateTransactionManager will still simply participate.

So in essence, in an EJB environment, use HibernateTransactionManager with Hibernate configured for JTATransaction. This will work both with and without existing JTA or EJB CMT transactions. In a non-EJB environment, use Spring's JtaTransactionManager: This uses JTA underneath too but has the advantage that you don't need to define a container-specific TransactionManagerLookup for Hibernate to get proper cache callbacks.

Juergen

Top

tysonnorris

Post subject:

Posted: Thu Dec 18, 2003 3:17 pm

Beginner

Joined: Tue Aug 26, 2003 6:24 pm
Posts: 45

Thanks for the feedback, again, Juergen - I really appreciate it.

There is actually one other problem - if I "commit" the transaction via spring, in addition to getting the spring warning about "Could not reset JDBC connection of Hibernate session", but I also get an error from hibernate:

Code:

DEBUG|10:15:28.128|org.springframework.orm.hibernate.SessionFactoryUtils|Closing Hibernate session
DEBUG|10:15:28.128|net.sf.hibernate.impl.SessionImpl|closing session
DEBUG|10:15:28.128|net.sf.hibernate.impl.SessionImpl|disconnecting session
DEBUG|10:15:28.128|net.sf.hibernate.util.JDBCExceptionReporter|SQL Exception
java.sql.SQLException: The transaction is no longer active - status: 'Committed'. No further JDBC access is al
lowed within this transaction.
        at weblogic.jdbc.wrapper.JTSConnection.checkIfRolledBack(JTSConnection.java:118)
        at weblogic.jdbc.wrapper.JTSConnection.checkConnection(JTSConnection.java:127)
        at weblogic.jdbc.wrapper.Connection.preInvocationHandler(Connection.java:67)
        at weblogic.jdbc.wrapper.JTSConnection_oracle_jdbc_driver_OracleConnection.getWarnings(Unknown Source)

        at net.sf.hibernate.impl.BatcherImpl.closeConnection(BatcherImpl.java:272)
        at net.sf.hibernate.impl.SessionImpl.disconnect(SessionImpl.java:3198)
        at net.sf.hibernate.impl.SessionImpl.close(SessionImpl.java:547)
        at org.springframework.orm.hibernate.SessionFactoryUtils.closeSessionIfNecessary(SessionFactoryUtils.j
ava:181)
        at org.springframework.orm.hibernate.HibernateTransactionManager.cleanupAfterCompletion(HibernateTrans
actionManager.java:363)
        at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformT
ransactionManager.java:178)
        at com.benefitpoint.cmp.data.AbstractDataManager.commitTransaction(AbstractDataManager.java:140)
        at jsp_servlet._temp.__census_edit._jspService(__census_edit.java:238)
        at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
        at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:431)
        at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.jav
a:6310)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
        at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
        at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3622)
        at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2569)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
WARN |10:15:28.128|net.sf.hibernate.util.JDBCExceptionReporter|SQL Error: 0, SQLState: null
ERROR|10:15:28.128|net.sf.hibernate.util.JDBCExceptionReporter|The transaction is no longer active - status: '
Committed'. No further JDBC access is allowed within this transaction.
ERROR|10:15:28.128|net.sf.hibernate.util.JDBCExceptionReporter|Cannot close connection
java.sql.SQLException: The transaction is no longer active - status: 'Committed'. No further JDBC access is al
lowed within this transaction.

So, what I've done is create a *new* spring TransactionManager, which is the same as HibernateTransactionManager, except that:
- doBegin() does NOT perform

Code:

txObject.getSessionHolder().setTransaction(session.beginTransaction());

when a JTA transaction does not currently exist

- doCommit() never executes

Code:

txObject.getSessionHolder().getTransaction().commit();

(since the only time a transaction will be used is when a JTA already exists, in which case it is commited by container.

I'm basically trying to emulate a transaction "SUPPORTED" configuration, where JTA will be used ONLY when an existing transaction is already active. I'm not sure if there is a better way to get hibernate (2.1, btw) to behave this way.

any thoughts?

thanks
tyson

This allows hibernate Session and JTA to take care of all transaction begin/commits, and uses existing

Top

jhoeller

Post subject:

Posted: Fri Dec 19, 2003 4:18 am

Senior

Joined: Wed Aug 27, 2003 6:04 am
Posts: 161
Location: Linz, Austria

You don't need to create your custom transaction manager for this. If Hibernate is configured to JTATransaction, beginTransaction and commit calls will simply participate in the existing transaction anyway! Omitting them will not make any difference to the best of my knowledge.

The Hibernate error that you're seeing originates in Session.close, when Hibernate tries to check for SQL warnings. Frankly, I believe that WebLogic is too restrictive here: It should allow for reading the state of a Connection even after a commit. In any case, we need to close the Session, so there's no obvious way around this call.

I just noted: The stack trace that you have posted is the result of HibernateTransactionManager having committed the JTA transaction. You did not have an existing JTA transaction there. If you run this within an existing JTA transaction, you should get neither the isReadOnly nor the getWarnings error!

Juergen

Top

tysonnorris

Post subject:

Posted: Fri Dec 19, 2003 3:18 pm

Beginner

Joined: Tue Aug 26, 2003 6:24 pm
Posts: 45

Quote:

The Hibernate error that you're seeing originates in Session.close, when Hibernate tries to check for SQL warnings. Frankly, I believe that WebLogic is too restrictive here: It should allow for reading the state of a Connection even after a commit. In any case, we need to close the Session, so there's no obvious way around this call.

Understood - I just wanted to make sure these warnings/errors aren't going to cause problems down the road.

I still don't think this provides the functionality I would like which is:
- if a JTA transaction exists use it
- if a JTA transaction DOES NOT exist, do nothing (no new JTA transaction)

The hibernate JTATransaction code will *always* use a JTA transaction (i.e. if one is not there, a new one is created) when spring tells hibernate to begin transaction in HibernateTransactionManager:

Code:

// add the Hibernate transaction to the session holder
         txObject.getSessionHolder().setTransaction(session.beginTransaction());

I think this would be a nice *hibernate* option, (thus my other post) independent of spring. That is, when hibernate is configured to use JTA transactions, why not have a config option that allows a "supports" behavior, instead of "requires"? I suppose the argument is that this is left to the application to decide when a transaction is "supported" or "required", and the application should only force hibernate to create a transaction (using session.beginTransaction()) when appropriate. Which bring me back to using a custom transaction manager in spring.

Also, I notice that if I create a custom transaction manager, there are several protected methods in HibernateTransactionObject that force me to either create my on HibernateTransactionObject, or noodle with my package placement of my transaction manager...

thanks for the feedback
tyson[/quote]

Top

jhoeller

Post subject:

Posted: Sun Dec 21, 2003 11:16 am

Senior

Joined: Wed Aug 27, 2003 6:04 am
Posts: 161
Location: Linz, Austria

You've hit an interesting spot here: Using EJB CMT with HibernateTransactionManager and Hibernate configured for JTATransaction will indeed always create a transaction with the default transaction definition settings, i.e. PROPAGATION_REQUIRED. This is what the latter propagation behavior implies.

Setting the propagation behavior to PROPAGATION_SUPPORTS (via td.setPropagationBehavior) will change the strategy: no transaction will be created if none exists - but the transaction manager won't bind a Hibernate Session to the thread for reuse either. The latter is an unfortunate side effect, as that propagation behavior is what you want.

I don't think that this needs to be addressed on the Hibernate side: Native transactions like there should not need to be concerned with transaction propagation strategies but simply always do what they're told to at that low level: begin, commit, and rollback actual datastore transactions.

For a solution, I've just reworked Spring's JtaTransactionManager respectively its superclass AbstractPlatformTransactionManager: In case of PROPAGATION_SUPPORTS, it will still activate transaction synchronization and thus allow for reusing the same Hibernate Session within such an "empty" transaction that is not backed by a datastore transaction.

So what I finally recommend for your requirements in an EJB CMT environment is using Spring's JtaTransactionManager[i] with [i]PROPAGATION_SUPPORTS. Combine this with Hibernate 2.1 which features automatic JTA detection, and configure Hibernate for a TransactionManagerLookup that matches your J2EE container.

This will give you all benefits that you want: proper transactional cache handling, not creating a new transaction if none exists, reuse of Hibernate Session even if no transaction. For the latter, you need to use JtaTransactionManager from the upcoming Spring 1.0 M4 - use a Spring CVS snapshot if you want to try it out immediately.

Juergen

Top

tysonnorris

Post subject:

Posted: Mon Dec 22, 2003 4:06 pm

Beginner

Joined: Tue Aug 26, 2003 6:24 pm
Posts: 45

Quote:

So what I finally recommend for your requirements in an EJB CMT environment is using Spring's JtaTransactionManager with PROPAGATION_SUPPORTS

This will give you all benefits that you want: proper transactional cache handling, not creating a new transaction if none exists, reuse of Hibernate Session even if no transaction. For the latter, you need to use JtaTransactionManager from the upcoming Spring 1.0 M4 - use a Spring CVS snapshot if you want to try it out immediately.

In trying to get the "reuse of Hibernate Session even if no transaction", I don't follow how the hibernate session is reused when specifying the JtaTransactionManager? I thought HibernateTransactionManager was required for this feature?

I may be tracing the code incorrectly - let me know if I'm mistaken.

I will try it out later today, but wanted to ask abou this confusing point first.

Thanks!
Tyson

Top

jhoeller

Post subject:

Posted: Tue Dec 23, 2003 6:58 am

Senior

Joined: Wed Aug 27, 2003 6:04 am
Posts: 161
Location: Linz, Austria

All Spring transaction managers derived from AbstractPlatformTransactionManager offer a TransactionSynchronization mechanism. SessionFactoryUtils, PersistenceManagerFactoryUtils, and DataSourceUtils will automatically register an opened Session / PersistenceManager / Connection with this synchronization mechanism, for reuse within the same transaction, and for automatic closing at transaction completion.

HibernateTransactionManager delegates to Hibernate's native Transaction API, automatically binding the underlying Hibernate Session to the thread at transaction begin. The difference with JtaTransactionManager is that Sessions will get bound to the thread lazily, when they are first used within a transaction - similar to JDBC Connections with JTA. But then, the behavior is practically the same in that the Session will be reused within the transaction and closed at the end.

The specific issue that I was referring to is that, with Spring 1.0 M3, transaction synchronization will just be active if JtaTransactionManager actually initiates a transaction - but not in the case of an existing JTA transaction, like from EJB CMT. I've changed that for 1.0 M4: Now, transaction synchronization will always be applied to the scope of the transaction that is under JtaTransactionManager's control, no matter if participating in an existing transaction or not.

Juergen

Top

tysonnorris

Post subject: JTATransaction problem - when there is NO transaction

Posted: Tue Jan 13, 2004 3:06 pm

Beginner

Joined: Tue Aug 26, 2003 6:24 pm
Posts: 45

As mentioned, I'm trying to implement a "Supports" transaction scenario. Now, when using propagation=SUPPORTS, I do NOT get a new JTA tx (as expected), but hibernate fails during flush - indicating "transaction already committed"...

Any ideas?

here is a log snippet:

Code:

DEBUG|11:03:05.637|org.springframework.jndi.JndiTemplate|Looking up JNDI object with name 'javax.transaction.UserTransaction'
DEBUG|11:03:05.653|org.springframework.transaction.jta.JtaTransactionManager|Using transaction object [ClientTM[devServer+10.0.4.85:7001+dev+t3+]]
DEBUG|11:03:05.684|com.benefitpoint.util.PropertiesWithStaticSupport|initialize : /platform.properties
WARN |11:03:05.684|com.benefitpoint.util.PropertiesWithStaticSupport|Value for property CONNECTION_POOL not found in properties file /platform.properties.
WARN |11:03:05.684|com.benefitpoint.util.PropertiesWithStaticSupport|Value for property CONNECTION_POOL_MAX not found in properties file /platform.properties.
WARN |11:03:05.684|com.benefitpoint.util.PropertiesWithStaticSupport|Value for property CONNECTION_POOL_INITIAL not found in properties file /platform.properties.
DEBUG|11:03:05.888|org.springframework.orm.hibernate.SessionFactoryUtils|Opening Hibernate session
DEBUG|11:03:06.13 |net.sf.hibernate.impl.SessionImpl|opened session
DEBUG|11:03:06.13 |org.springframework.orm.hibernate.SessionFactoryUtils|Registering transaction synchronization for Hibernate session
DEBUG|11:03:06.28 |org.springframework.transaction.support.TransactionSynchronizationManager|Bound value [org.springframework.orm.hibernate.SessionHolder@172b8dd] for key [net.sf.hibernate.impl.SessionFactoryImpl@24808] to thread [ExecuteThread: '14' for queue: 'default']
DEBUG|11:03:06.28 |net.sf.hibernate.impl.SessionImpl|loading [com.benefitpoint.cmp.marketing.request.RequestSetup#288]
DEBUG|11:03:06.28 |net.sf.hibernate.impl.SessionImpl|attempting to resolve [com.benefitpoint.cmp.marketing.request.RequestSetup#288]
DEBUG|11:03:06.28 |net.sf.hibernate.impl.SessionImpl|object not resolved in any cache [com.benefitpoint.cmp.marketing.request.RequestSetup#288]
DEBUG|11:03:06.28 |net.sf.hibernate.persister.EntityPersister|Materializing entity: [com.benefitpoint.cmp.marketing.request.RequestSetup#288]
DEBUG|11:03:06.44 |net.sf.hibernate.impl.BatcherImpl|about to open: 0 open PreparedStatements, 0 open ResultSets
DEBUG|11:03:06.44 |net.sf.hibernate.impl.BatcherImpl|prepared statement get: select requests0_.REQUEST_SETUP_ID as REQUEST_1_0_ from REQUEST_SETUP requests0_ where requests0_.REQUEST_SETUP_ID=?
DEBUG|11:03:06.44 |net.sf.hibernate.impl.BatcherImpl|preparing statement
DEBUG|11:03:06.44 |net.sf.hibernate.type.IntegerType|binding '288' to parameter: 1
DEBUG|11:03:06.44 |net.sf.hibernate.loader.Loader|processing result set
DEBUG|11:03:06.44 |net.sf.hibernate.loader.Loader|result row: 288
DEBUG|11:03:06.44 |net.sf.hibernate.loader.Loader|Initializing object from ResultSet: 288
DEBUG|11:03:06.44 |net.sf.hibernate.loader.Loader|Hydrating entity: com.benefitpoint.cmp.marketing.request.RequestSetup#288
DEBUG|11:03:06.60 |net.sf.hibernate.loader.Loader|done processing result set (1 rows)
DEBUG|11:03:06.60 |net.sf.hibernate.impl.BatcherImpl|done closing: 0 open PreparedStatements, 0 open ResultSets
DEBUG|11:03:06.60 |net.sf.hibernate.impl.BatcherImpl|closing statement
DEBUG|11:03:06.60 |net.sf.hibernate.loader.Loader|total objects hydrated: 1
DEBUG|11:03:06.60 |net.sf.hibernate.impl.SessionImpl|resolving associations for [com.benefitpoint.cmp.marketing.request.RequestSetup#288]
DEBUG|11:03:06.60 |net.sf.hibernate.impl.SessionImpl|collection not cached
DEBUG|11:03:06.75 |net.sf.hibernate.impl.SessionImpl|collection not cached
DEBUG|11:03:06.75 |net.sf.hibernate.impl.SessionImpl|done materializing entity [com.benefitpoint.cmp.marketing.request.RequestSetup#288]
DEBUG|11:03:06.75 |net.sf.hibernate.impl.SessionImpl|initializing non-lazy collections
DEBUG|11:03:06.75 |net.sf.hibernate.impl.SessionImpl|initializing collection [com.benefitpoint.cmp.marketing.request.RequestSetup.attachmentTypes#288]
DEBUG|11:03:06.75 |net.sf.hibernate.impl.BatcherImpl|about to open: 0 open PreparedStatements, 0 open ResultSets
DEBUG|11:03:06.75 |net.sf.hibernate.impl.BatcherImpl|prepared statement get: select request_0_.ATTACHMENT_TYPE_ID as ATTACHME2___, request_0_.REQUEST_SETUP_ID as REQUEST_1___ from REQUEST_SETUP_ATTACH_TYPE request_0_ where request_0_.REQUEST_SETUP_ID=?
DEBUG|11:03:06.75 |net.sf.hibernate.impl.BatcherImpl|preparing statement
DEBUG|11:03:06.75 |net.sf.hibernate.type.IntegerType|binding '288' to parameter: 1
DEBUG|11:03:06.91 |net.sf.hibernate.loader.Loader|result set contains (possibly empty) collection: [com.benefitpoint.cmp.marketing.request.RequestSetup.attachmentTypes#288]
DEBUG|11:03:06.91 |net.sf.hibernate.impl.SessionImpl|uninitialized collection: initializing
DEBUG|11:03:06.91 |net.sf.hibernate.loader.Loader|processing result set
DEBUG|11:03:06.91 |net.sf.hibernate.loader.Loader|done processing result set (0 rows)
DEBUG|11:03:06.91 |net.sf.hibernate.impl.BatcherImpl|done closing: 0 open PreparedStatements, 0 open ResultSets
DEBUG|11:03:06.91 |net.sf.hibernate.impl.BatcherImpl|closing statement
DEBUG|11:03:06.91 |net.sf.hibernate.impl.SessionImpl|1 collections were found in result set
DEBUG|11:03:06.91 |net.sf.hibernate.impl.SessionImpl|collection fully initialized: [com.benefitpoint.cmp.marketing.request.RequestSetup.attachmentTypes#288]
DEBUG|11:03:06.91 |net.sf.hibernate.impl.SessionImpl|1 collections initialized
DEBUG|11:03:06.91 |net.sf.hibernate.impl.SessionImpl|initializing collection [com.benefitpoint.cmp.marketing.request.RequestSetup.setupPlanTypes#288]
DEBUG|11:03:06.91 |net.sf.hibernate.impl.BatcherImpl|about to open: 0 open PreparedStatements, 0 open ResultSets
DEBUG|11:03:06.91 |net.sf.hibernate.impl.BatcherImpl|prepared statement get: select request_0_.INCL_CONTRIBUTIONS_IND as INCL_CON2___, request_0_.INCL_ELIGIBILITY_RULES_IND as INCL_ELI3___, request_0_.INCL_PLAN_INSTRUCTIONS_IND as INCL_PLA4___, request_0_.REQUEST_SETUP_ID as REQUEST_1___, request_0_.PLAN_TYPE_ID as PLAN_TYP5___ from REQUEST_SETUP_PLAN_TYPE request_0_ where request_0_.REQUEST_SETUP_ID=?
DEBUG|11:03:06.91 |net.sf.hibernate.impl.BatcherImpl|preparing statement
DEBUG|11:03:06.91 |net.sf.hibernate.type.IntegerType|binding '288' to parameter: 1
DEBUG|11:03:06.106|net.sf.hibernate.loader.Loader|result set contains (possibly empty) collection: [com.benefitpoint.cmp.marketing.request.RequestSetup.setupPlanTypes#288]
DEBUG|11:03:06.106|net.sf.hibernate.impl.SessionImpl|uninitialized collection: initializing
DEBUG|11:03:06.106|net.sf.hibernate.loader.Loader|processing result set
DEBUG|11:03:06.106|net.sf.hibernate.loader.Loader|done processing result set (0 rows)
DEBUG|11:03:06.106|net.sf.hibernate.impl.BatcherImpl|done closing: 0 open PreparedStatements, 0 open ResultSets
DEBUG|11:03:06.106|net.sf.hibernate.impl.BatcherImpl|closing statement
DEBUG|11:03:06.106|net.sf.hibernate.impl.SessionImpl|1 collections were found in result set
DEBUG|11:03:06.106|net.sf.hibernate.impl.SessionImpl|collection fully initialized: [com.benefitpoint.cmp.marketing.request.RequestSetup.setupPlanTypes#288]
DEBUG|11:03:06.106|net.sf.hibernate.impl.SessionImpl|1 collections initialized
DEBUG|11:03:06.200|com.benefitpoint.cmp.marketing.request.RequestController|new request setup id was:288
DEBUG|11:03:06.200|org.springframework.transaction.support.TransactionSynchronizationManager|Triggering beforeCommit synchronization
DEBUG|11:03:06.200|org.springframework.orm.hibernate.SessionFactoryUtils|Flushing Hibernate session on transaction synchronization
DEBUG|11:03:06.200|net.sf.hibernate.impl.SessionImpl|flushing session
DEBUG|11:03:06.200|net.sf.hibernate.impl.SessionImpl|Flushing entities and processing referenced collections
DEBUG|11:03:06.200|net.sf.hibernate.impl.WrapVisitor|Wrapped collection in role: com.benefitpoint.cmp.marketing.request.RequestSetup.setupPlanTypes
DEBUG|11:03:06.200|net.sf.hibernate.impl.WrapVisitor|Wrapped collection in role: com.benefitpoint.cmp.marketing.request.RequestSetup.attachmentTypes
DEBUG|11:03:06.216|net.sf.hibernate.impl.SessionImpl|Collection found: [com.benefitpoint.cmp.marketing.request.RequestSetup.setupPlanTypes#288], was: [<unreferenced>]
DEBUG|11:03:06.216|net.sf.hibernate.impl.SessionImpl|Collection found: [com.benefitpoint.cmp.marketing.request.RequestSetup.attachmentTypes#288], was: [<unreferenced>]
DEBUG|11:03:06.216|net.sf.hibernate.impl.SessionImpl|Processing unreferenced collections
DEBUG|11:03:06.216|net.sf.hibernate.impl.SessionImpl|Collection dereferenced: [com.benefitpoint.cmp.marketing.request.RequestSetup.setupPlanTypes#288]
DEBUG|11:03:06.216|net.sf.hibernate.impl.SessionImpl|Collection dereferenced: [com.benefitpoint.cmp.marketing.request.RequestSetup.attachmentTypes#288]
DEBUG|11:03:06.216|net.sf.hibernate.impl.SessionImpl|Scheduling collection removes/(re)creates/updates
DEBUG|11:03:06.216|net.sf.hibernate.impl.SessionImpl|Flushed: 0 insertions, 0 updates, 0 deletions to 1 objects
DEBUG|11:03:06.216|net.sf.hibernate.impl.SessionImpl|Flushed: 2 (re)creations, 0 updates, 2 removals to 4 collections
DEBUG|11:03:06.232|net.sf.hibernate.impl.Printer|listing entities:
DEBUG|11:03:06.232|net.sf.hibernate.impl.Printer|com.benefitpoint.cmp.marketing.request.RequestSetup{attachmentTypes=[103, 107, 128], setupPlanTypes=[RequestSetupPlanType{inclContributionsInd=true, inclEligibilityRulesInd=true, inclPlanInstructionsInd=true}, RequestSetupPlanType{inclContributionsInd=true, inclEligibilityRulesInd=true, inclPlanInstructionsInd=true}], id=288}
DEBUG|11:03:06.232|net.sf.hibernate.impl.SessionImpl|executing flush
DEBUG|11:03:06.232|net.sf.hibernate.collection.BasicCollectionPersister|Inserting collection: [com.benefitpoint.cmp.marketing.request.RequestSetup.setupPlanTypes#288]
DEBUG|11:03:06.232|net.sf.hibernate.impl.BatcherImpl|about to open: 0 open PreparedStatements, 0 open ResultSets
DEBUG|11:03:06.232|net.sf.hibernate.impl.BatcherImpl|prepared statement get: insert into REQUEST_SETUP_PLAN_TYPE (REQUEST_SETUP_ID, PLAN_TYPE_ID, INCL_CONTRIBUTIONS_IND, INCL_ELIGIBILITY_RULES_IND, INCL_PLAN_INSTRUCTIONS_IND) values (?, ?, ?, ?, ?)
DEBUG|11:03:06.232|net.sf.hibernate.impl.BatcherImpl|preparing statement
DEBUG|11:03:06.263|net.sf.hibernate.util.JDBCExceptionReporter|SQL Exception
java.sql.SQLException: The transaction is no longer active - status: 'Committed'. No further JDBC access is allowed within this transaction.
   at weblogic.jdbc.wrapper.JTSConnection.checkIfRolledBack(JTSConnection.java:118)
   at weblogic.jdbc.wrapper.JTSConnection.checkConnection(JTSConnection.java:127)
   at weblogic.jdbc.wrapper.Connection.prepareStatement(Connection.java:316)
   at weblogic.jdbc.wrapper.JTSConnection.prepareStatement(JTSConnection.java:425)
   at net.sf.hibernate.impl.BatcherImpl.getPreparedStatement(BatcherImpl.java:233)
   at net.sf.hibernate.impl.BatcherImpl.prepareStatement(BatcherImpl.java:57)
   at net.sf.hibernate.impl.BatcherImpl.prepareBatchStatement(BatcherImpl.java:105)

Thanks for all the help!

tyson

Top

tysonnorris

Post subject:

Posted: Tue Jan 13, 2004 5:30 pm

Beginner

Joined: Tue Aug 26, 2003 6:24 pm
Posts: 45

ok - I think I figured out the solution:

set the SYNCHRONIZATION_ON_ACTUAL_TRANSACTION in the JtaTransactionManager instance. This way, when a JTA tx exists, it is used. When it is not found, *NO* tx is used. I can also add app logic - say if I wanted to use JDBC tx in case of no JTA tx - to switch transaction managers. I will try that a later day.

jtaTransactionManager.setTransactionSynchronization(JtaTransactionManager.SYNCHRONIZATION_ON_ACTUAL_TRANSACTION);

thanks again!

tyson

Top

tysonnorris

Post subject:

Posted: Tue Jan 13, 2004 7:48 pm

Beginner

Joined: Tue Aug 26, 2003 6:24 pm
Posts: 45

ok, I spoke too soon :)

I think my final issue deals with using JTAtransactionManager and a hibernate interceptor - how to do it?

I need to use an interceptor for audit logging and custom dirty checking.

any ideas?

thanks
tyson

Top

Page 1 of 2

[ 17 posts ]

Go to page 1, 2 Next

Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum