Hi... i am a begineers using Hibernate...

I am developing a Swing Application, and i am using thread (Foxtrot api) to managed swing events and avoid the freeze on swing components..

When a hibernate session is create and set in threadSession i receive a exception about: Two session open in the applications and nothing happens...

Please help me..

You end up with two sessions because there are two threads are trying to do something. It should not be a problem if a some sort of AOP/proxy session management takes place. However you should be vary that because those threads are not in parent/child relationships the transaction propagation will be limited for a thread call chains. Most of the time it should not be a problem.
Please see this article for some information and ideas:
http://www.onjava.com/pub/a/onjava/2005 ... tions.html

Note: you do not have to use Spring, the same concept can be easily implemented with HiveMind, straight AspectJ, or CGLib enhancements.

This is unnecessary and outdated stuff, Hibernate3 has built-in persistence context propagation on a thread. Please stop posting it as the cure-all whenever somebody doesn't understand transactions or threads.

http://hibernate.org/42.html

I would not say that the article describes what needs to be done to complement
http://hibernate.org/42.html

Transaction demarcation has to be defined somewhere and proxy based interceptors are nice way of getting rid of repetitions of code like this:
try {
factory.getCurrentSession().beginTransaction();

// Do some work

} catch (RuntimeException e) {
factory.getCurrentSession().getTransaction().rollback();
throw e; // or display error message
}

The code goes in the interceptor and gets applied wisely by interceptor.

Yes, and the interceptor is extremely trivial and has 10 lines of code (3 are important). You don't need a framework for the simple common case, and certainly not one that comes with 1000 page books.

http://cvs.sourceforge.net/viewcvs.py/h ... &view=auto

Thanks.. i will try thats suggestiongs..

Christian,

It does not look like that interceptor actually does correct Transaction context propagation at least for JDBCTransaction.
The interceptor code starts and finishes transaction indeed, but I am afraid it might fail if the target method will call another instrumented class or method. In this case sequence will look like
transaction.begin()
transaction.begin()
transaction.commit()
transaction.commit() //what will happens here?


Method JDBCTransaction.begin() is reentrant, it does nothing if transaction already has started, but commit does its job on first invocation. I think JDBCTransaction should count begin requests and really commit transaction on matched commit call.
Or similar logic could be implemented in the interceptor ( stack based rather counter based approach ).

And some framework is necessary to apply interceptor, either JBossAOP or AspectJ, or simplified proxy bases solution like HiveMind, Spring, CGLib.

And JBossAOP is not the easiest to use IMO

This is for the _most common case_. No transaction propagation needed. And JBossAOP is one pointcut expressions to apply it to the right methods. Nothing is difficult about this.

Wow! It is not that different from JDBC autocommit mode then, which is bad practice for production grade code.
I would say that most common is the situation where transaction propagation does required.

This has _nothing_ to do with auto commit mode.

It is functionally close and that is bad IMO.

Dear Konstantin,

your assumption that "auto commit mode" is somehow connected to a simple transaction interceptor has nothing to do with reality. Please make things not more complex than they already are for poor Hibernate users. We still appreciate you helping out on our forums, but KISS.

Thanks

One of you is not reading the same thread when replying to the other one ;-p

Most definitely :)

Folks, I spent all week writing and explaining about transactions. I'm totally sick of it, I have to consider every little detail so that I don't cause more confusion with an already deeply confused and misled audience.

I have a real problem if someone makes my work even more difficult by spreading half-truth, "IMHO", and other things they have heard from their best buddy. Either put up or shut up if you don't have a point to make that holds water.