Hi all,
In this scenario:
- A CPU with N cores
- some CPU-bound operation that can easily be split in N parallel jobs
- need for repeatable-read or serializable transactions
I would love to split the job to make use of multi-threading, but I have some transactional concerns: each thread needs to open it's own thread, but I would like them to share the same transaction.
I imagine something like XA transaction semantics could be used for commits (all participants on same DB), but just for simplicity imagine my expensive N jobs are doing "read-only work".
What I would like to guarantee is that the N threads are all working on the same data:
if any other thread alive commits/flushes some change to DB I want to see all changes
either before my N threads begun transaction, or after my N threads:
I want to ensure that if any thread works on entity1 this will contain the same information that other threads are receiving.
I was thinking about some locking mechanism to be build in the sessionfactory to permit opening a N-list of sessions and let other treads wait, but locks need to be owned by one single thread, and sessions can't be opened by one thread to be handed over to another one.. right? But:
A)I've seen some
ThreadLocal s in the source... I would need to share some data.
B)I still am not sharing a database transaction, so some other service not using my locked down SessionFactory could break my design.
Did somebody address this problem?
Would it be possible to use something like a single DB transaction shared among different Sessions?
I would love some api as
Code:
SessionProducer sp = SessionFactory.getNSessionsTicket(int n); //call once, transaction begins (not lazily)
Session session = sp.getASession(); //each thread gets one
This "SessionProducer" is the only one needing ThreadSafety, but when it is build in the SessionFactory all special session datastructures should be replicated in the particular ThreadLocals (I could get this effect overriding the initialize method in ThreadLocal).
Maybe some of these structures could need sharing (and consequently being guarded for concurrency)