Hibernate: session.createQuery and session cache

Question

What I have:

I have integrate State Pattern in my app. That means that when I change state of some entity it may cause chain reaction. Means the states of related entities also may change, and than the states of related entities to those entities and so on.

Also I use Hibernate conversatetion, which means I use MANUL flush mode.

public void handler() {
  session = beginHibernateConversation(); //open new transaction and new session (if it's needed)
  entity.changeState(session); //call chain reaction
  finishhibernateConversation(session); //manual flush, commit, and if it's needed - close session
}

What a problem:

When I use manual flush mode all changes are made to DB only on finishhibernateConversation(session) method.

I need use session.createQuery method inside changeState(session) method. But I can't see the actual entities states! Beacause all changes are stored in unflushed session and because session.createQuery doesn't matter about session context.

Question:

How to make session.createQuery consider session cache?

A little example:

For example I have Person - Job relationship (one-to-many). When I change state of one job to full time I need update all other related jobs (because person could work only on one full time job).

So, I do (inside of person UPDATE request)

job1.changeState('full time')
[inside the first method] session.createQuery("from Job where person.id = (:id) state in (:states)").

The problem is that the second query isn't correct, because it doesn't consider about already changed state of job1

David Weinberg · Accepted Answer · 2013-11-25 19:04:12Z

1

You have a few options here, but there is no easy change for this problem.

1) Use FlushMode.AUTO. With auto flush, Hibernate flushes before doing a query to avoid this problem. There shouldn't be any conflict between auto flush and the pattern you're using, but there are other problems with auto flush. Generally in a highly concurrent environment, you can have problems with this as it will keep long database transactions.

2) When you are making a query like this, go off of the root object and query in memory. In this example, that would be something like getting the person and iterating through its Job collection.

3) Create a ThreadLocal cache that keeps track of things you might query on. This is the worst of all options, but is sometimes necessary.

answered Nov 25, 2013 at 19:04

David Weinberg

5333 silver badges9 bronze badges

Sign up to request clarification or add additional context in comments.

2 Comments

VB_ Over a year ago

1) I can't use FlushMode.AUTO because of conversation. Conversation means that if user press "CANCEL" button all changes should be reverted. 3) It's realy the worst case 2) but, please, explaine me the second alternative.

David Weinberg Over a year ago

Auto flush will work in that scenario (it's flushing to the database, but it is not committing the database transaction). It will just result in database locks which will be bad, so not recommended. What I meant for option two was something like: for (Job job : person.getJobs()) { if (job.getState().equals(State.SomeValue)) { return job; } } Or the like.

Collectives™ on Stack Overflow

Hibernate: session.createQuery and session cache

1 Answer 1

2 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

2 Comments

Your Answer

Sign up or log in

Post as a guest

Related