My application is heavily using thread pool, even a method of a class may be executed in another thread using aspectj advice.

This brings me a problem of how to design my database entity using Hibernate JPA implementation, especially with one-to-many, many-to-many and so forth. The problem is my application uses session-per-thread pattern that EntityManager is stored in ThreadLocal, so the entity obtained in one thread is frequently passed to another thread. If I have any one-to-many like mapping in entity, the lazy fetching won't work since the entity is out of persistence.

The workaround I see is calling merge() to attach entity to thread's entity manager before any access to lazy fetching entity, but this requires a wrapper class for entity which call merge() in every getter of associated entity. This has a drawback that if I change some fields of the entity but not want to merge to persistence right now, calling a getter will screw up.

I did some research but not got any better solution. I was wondering this should be a common practice for threadpool oriented application. there must be a best practice pattern.

another way is never using such one-to-many facility but that introduces much boring coding burden.

Does anyone have a better idea?

Hi,
I've never heard before of a threadpool oriented application; I do use threadpools myself in several occasions, but this sounds like an excessive usage, I hope you have good reasons for this and have done good research before deciding for this pattern.

How are you going to handle transactions? Also make sure when one thread receives the entity instance, the other threads have no more references to it: including the loading Session which should be closed. Transactions on the JDBC datasource are also commonly bound to the running thread, so you'll have to deal with that too.

The Hibernate Session is designed to wrap a full "unit of work", if you can't you should make sure you pass only the object identifiers to the alternative thread so that it will re-load the entity creating a new instance. If you configure second level caching, it won't need to reload from the database.

Thanks sanne.grinovero.

The intention to use threadpool like this is my application consists of multiple services based on message.
So every service need to dispatch message to worker thread which also involves passing entity.
I also thinking passing id and reloading it, but it introduces lots of DB connection.

Looks like the only way is to look into secondary cache right now.