Hibernate's session-per-conversation & query unflushed entities
here's the context :
we are currently writing an application which is web based (flex front end). The server side is implemented with Java, using hibernate for ORM.
The specificity of this application is that it implements a conversation with the user. That means that the user is opening a conversation and before it decides to save (or cancel) the conversation, it performs many operations on objects which are mapped as hibernate entities.For instance :
- open a conversation
- create an object A
- save it in the session
- query it
- update it
- etc...
- save the conversation (flush the session...)
and then another conversation cycle starts.
We chose naturally the session-per-conversation pattern to implement this way to work.
Let me remind you the principle : the hibernate session is created once when the user decides to start a conversation, its flush mode being set to MANUAL, and from now it is disconnected between each transaction until the user decide to end the conversation which is the only time when we explicitly flush the session (and so write the data from session to DB).Edit
In the session-per-conversation pattern, each operation is made in a transaction that is commited. For instance, let's say we have two services, one called addObject() and the other called getObject(). The process is the following:- open a conversation (=> the session is created with flush mode set to MANUAL and bind it in the ManagedSessionContext that held the current session)
- call the addObject() service which gets the conversation session, opens a transaction, create an entity, save it, disconnect the session and finally commit the transaction
- call the getObject() service which gets the conversation session, opens a transcation, get the object, disconnect the session and finall开发者_运维问答y commit the transaction
- save the conversation by opening a transaction, flushing the session and then commiting the transaction.
Here we see that I cannot flush the session without commiting the transaction because the goal is precisely to commit the transaction after each service-like operation.
We had no problem at all until we want to query some unflushed entities! Because if we want to use this kind of conversation, that's because we want to be in a state of "simulation' until we explicitly flush the session. But it appears that unflushed entities cannot be loaded using hibernate criterias or HQL except if a flush() is performed on the session which leads to loose all benefit from the session-per-conversation pattern...
So my question is :
Can we configure this behaviour? (ie can we enable querying the session cache event if the session is not flushed?)
As it seems that the answer is no (any contradictor will be welcome!), 2nd question : Is there a smart way to make it on my own without perverting the probably intelligent and considered hibernate's way of doing?
Hoping that my english is understandable, I thank you all by advance. (Let me precise that this question has also been posted to the hibernate user forum)
Ben
From the Hibernate API
Flushing is the process of synchronizing the underlying persistent store with persistable state held in memory.
Flush does not necessarily mean that you write your changes to the DB. It means that the state in memory is up-to-date. Flush only writes changes to the DB if your DB does not support transactions or you do not work in transaction.
If you work with transactions and your DB supports transactions, e.g., MySQL with InnoDB, then you can flush whenever you like without writing anything to the DB. The changes are not written to the DB until you call Transaction.commit()
.
精彩评论