I think the ReadWriiteReentrantLock data structure is the right one to deal with this situation : http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html
(Thanks to Cedric Champeau for the suggestion) Le 2/8/14 10:26 AM, Emmanuel Lécharny a écrit : > Le 2/8/14 8:28 AM, Kiran Ayyagari a écrit : >> On Fri, Feb 7, 2014 at 11:29 PM, Emmanuel Lécharny >> <[email protected]>wrote: >> >>>>> This is not trivial, as we want to make it as easy as possible for our >>>>> users. Typically, how should an operation know which kind of transaction >>>>> it is dealing with ? Let's have a look at such an operation : >>>>> >>>>> insert : >>>>> // check if we are already into a txn >>>>> if (in transaction) (1) >>>>> then >>>>> process operation >>>>> else >>>>> start transaction (2) >>>>> process operation >>>>> commit operation >>>>> >>>>> so far, it seems ok, but what if another thread has started a >>>>> transaction *just* after the test (1) and before (2) ? This is >>> complicated. >>>>> hmmm, how about using ThreadLocal, >>>> and not sure we need to branch based on the presence of txn handle, the >>>> start transaction(2) >>>> should always give the txn handle present in ThreadLocal >>> That would work if only we were in a single thread environment... In our >>> case, we have no idea how many threads will try to write data in Mavibot. >>> >>> ThreadLocal is meant for multithreaded environments > Sure, but in this case, it won't help, as a ThreadLocal storage will be > associated with one single thread (and each thread will have a different > insance), when we are trying to avoid many threads to access one > resource concurrently. I'm failing to see how we could use TLS in this > case. Do you have something in mind ? > > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
