Hi,

Currently, in our application, we start a transaction early in each page request regardless whether anything will be changed or not. And then close it at the end. I suspect this might be bad on the performance.

So could it be possible to start a transaction only when anything is saved to the database during a page request? (And close it at the end of the page request). Could this be done by interceptor perhaps? Or is this whole idea bad?

Btw, we use session-per-request.


/Carl

imho, opening a tran at the begin_request() is looking for bad performance down the road.



imho, your DAO should have the ability to open and commit/close the tran when you call Save()/Update()/SaveOrUpdate(). check out the Cuyahoga app for a general idea on how you might do this. Also, the Castle Project has a good looking GenericDAO that other DAOs can extend:

http://www.castleproject.org/index.php/ ... GenericDao

-d

In our design we don't evict the entities. We keep the session open during the entire page request. So changes are made by just changing the entities without any explicit calls to an update function in our DAO. And I'm afraid we are to long down the road on this design. Besides we want all changes made during a page request to really be inside one single transaction.

So again, might it be possible to use interceptor (or some other technique) to just begin the transaction when something has changed and its about to be persisted to the database?

I had a similar question awhile ago and received the following response.



http://forum.hibernate.org/viewtopic.php?t=944697

I'm not an expert on transactions, but, if what this Hibernate developer suggests is true, read operations should be wrapped in the transaction as well.

What I do is use the Open Session In View pattern to open/close the session, but actually begin a transaction just before calling the SAVE method, and then commit right after it (or rollback, if required). I let NH care of all the different updates it has to do to referenced object inside the one I'm saving.
It' is also true that I don't have (for now) a very complex logic in my pages...

jemiller> Thanks! I guess we will continue using our approach, unless someone else has any suggestions that will not require a major redesign.
The performance isn't at all bad at the moment, but we haven't really tried it for larger amounts of data and users yet.