You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@symas.com> on 2014/02/07 11:12:08 UTC
[Mavibot] Transaction discussion
Hi,
there are two things to consider in order to support transactions :
- we could have automatique transaction per operation (ie, we don't have
to start a transaction before issuing an operation)
- we can also create a transaction explicitely, and use it across more
than one operation.
We want to support both cases.
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.
One easy solution would be to pass a transaction as a parameter. If this
parameter is null, then we can start a new transaction (but again, we
will have difficulties if we have to check if this parameter is null
inside the operation, for the exact same reason thanseen before).
At the end of teh day, it's probably better to force people to create
the transaction *before* starting an operation :
txn = begingTransaction()
insert( txn )
txn.commit()
That's not really beautiful, but it will be safe. I'm also trying to
think about other options...
Re: [Mavibot] Transaction discussion
Posted by Emmanuel Lécharny <el...@gmail.com>.
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 <el...@gmail.com>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
Re: [Mavibot] Transaction discussion
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/8/14 8:28 AM, Kiran Ayyagari a écrit :
> On Fri, Feb 7, 2014 at 11:29 PM, Emmanuel Lécharny <el...@gmail.com>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
Re: [Mavibot] Transaction discussion
Posted by Kiran Ayyagari <ka...@apache.org>.
On Fri, Feb 7, 2014 at 11:29 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Le 2/7/14 11:22 AM, Kiran Ayyagari a écrit :
> > On Fri, Feb 7, 2014 at 3:42 PM, Emmanuel Lécharny <elecharny@symas.com
> >wrote:
> >
> >> Hi,
> >>
> >> there are two things to consider in order to support transactions :
> >>
> >> - we could have automatique transaction per operation (ie, we don't have
> >> to start a transaction before issuing an operation)
> >> - we can also create a transaction explicitely, and use it across more
> >> than one operation.
> >>
> >> We want to support both cases.
> >>
> >> +1 , IMHO implicit transaction support is a MUST
>
> A complex MUST...
>
>
> >> 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
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
http://keydap.com
Re: [Mavibot] Transaction discussion
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 2/7/14 11:22 AM, Kiran Ayyagari a écrit :
> On Fri, Feb 7, 2014 at 3:42 PM, Emmanuel Lécharny <el...@symas.com>wrote:
>
>> Hi,
>>
>> there are two things to consider in order to support transactions :
>>
>> - we could have automatique transaction per operation (ie, we don't have
>> to start a transaction before issuing an operation)
>> - we can also create a transaction explicitely, and use it across more
>> than one operation.
>>
>> We want to support both cases.
>>
>> +1 , IMHO implicit transaction support is a MUST
A complex MUST...
>> 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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [Mavibot] Transaction discussion
Posted by Kiran Ayyagari <ka...@apache.org>.
On Fri, Feb 7, 2014 at 3:42 PM, Emmanuel Lécharny <el...@symas.com>wrote:
> Hi,
>
> there are two things to consider in order to support transactions :
>
> - we could have automatique transaction per operation (ie, we don't have
> to start a transaction before issuing an operation)
> - we can also create a transaction explicitely, and use it across more
> than one operation.
>
> We want to support both cases.
>
> +1 , IMHO implicit transaction support is a MUST
> 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
> One easy solution would be to pass a transaction as a parameter. If this
> parameter is null, then we can start a new transaction (but again, we
> will have difficulties if we have to check if this parameter is null
> inside the operation, for the exact same reason thanseen before).
>
> At the end of teh day, it's probably better to force people to create
> the transaction *before* starting an operation :
>
> it would be better if we can avoid this, but this is just a wish from my
view
> txn = begingTransaction()
> insert( txn )
> txn.commit()
>
> That's not really beautiful, but it will be safe. I'm also trying to
> think about other options...
>
--
Kiran Ayyagari
http://keydap.com