3:36 p.m.
Hey Manik,
Do not need Mircea's help. I turned on debugger and went to investigate
why I was getting NPEs in those invocations. So now I have first working
version of locking/unlocking working with transactions (see
SyncReplLockingTest). Will add more tests and continue to play with this
one.
All in all - loads of fun. As soon as I am done with this one and
implicit transactions I want more tasks :)
Regards,
Vladimir
3:05 a.m.
On 12 May 2009, at 21:36, Vladimir Blagojevic wrote:
Hey Manik,
Do not need Mircea's help. I turned on debugger and went to
investigate why I was getting NPEs in those invocations. So now I
have first working version of locking/unlocking working with
transactions (see SyncReplLockingTest). Will add more tests and
continue to play with this one.
Great!
All in all - loads of fun. As soon as I am done with this one and
implicit transactions I want more tasks :)
Fantastic. There's always more stuff that needs doing, so ping me
when you're ready. :-)
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
9:12 a.m.
On 12 May 2009, at 21:36, Vladimir Blagojevic wrote:
Hey Manik,
Do not need Mircea's help. I turned on debugger and went to
investigate why I was getting NPEs in those invocations. So now I
have first working version of locking/unlocking working with
transactions (see SyncReplLockingTest). Will add more tests and
continue to play with this one.
By way of tests you want to make sure:
1. Concurrent non-tx writes on the same node are held back by the lock
2. Concurrent non-tx writes on a different node are held back by the
lock
3. As 1 but with concurrent tx writes
4. As 2 but with concurrent tx writes
5. Test that locks are released on commit even if there is no
explicit unlock()
6. As 5 but with rollback
7. Test that locks are released on unlock if the key is not modified
in the tx
8. Test that locks are NOT released despite unlock if the key is
modified in the tx. Should only unlock on commit/rollback in this case.
The above should also be tested with Invalidation as well as
Distribution.
And of course then there is the implicit eager locking on
transactions, as you mention. :-)
All in all - loads of fun. As soon as I am done with this one and
implicit transactions I want more tasks :)
Regards,
Vladimir
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
2:33 a.m.
On 5/13/09 4:12 PM, Manik Surtani wrote:
By way of tests you want to make sure:
1. Concurrent non-tx writes on the same node are held back by the lock
2. Concurrent non-tx writes on a different node are held back by the
lock
3. As 1 but with concurrent tx writes
4. As 2 but with concurrent tx writes
5. Test that locks are released on commit even if there is no
explicit unlock()
6. As 5 but with rollback
7. Test that locks are released on unlock if the key is not modified
in the tx
8. Test that locks are NOT released despite unlock if the key is
modified in the tx. Should only unlock on commit/rollback in this case.
I finished all tests except 8. I am confused with implied semantic of
unlock. What is the point of having unlock then? If we are allowing
locking with transactions only why do we need unlock?
3:41 a.m.
On 5/19/09 9:33 AM, Vladimir Blagojevic wrote:
> 8. Test that locks are NOT released despite unlock if the key is
> modified in the tx. Should only unlock on commit/rollback in this case.
>
I finished all tests except 8. I am confused with implied semantic of
unlock. What is the point of having unlock then? If we are allowing
locking with transactions only why do we need unlock?
Thought a little bit more about this. Does point 8 imply that key should
be released on unlock if it was *not* modified and on commit/rollback if
it was modified?
5 a.m.
On 19 May 2009, at 09:41, Vladimir Blagojevic wrote:
On 5/19/09 9:33 AM, Vladimir Blagojevic wrote:
>> 8. Test that locks are NOT released despite unlock if the key is
>> modified in the tx. Should only unlock on commit/rollback in this
>> case.
>>
> I finished all tests except 8. I am confused with implied semantic
> of unlock. What is the point of having unlock then? If we are
> allowing locking with transactions only why do we need unlock?
>
Thought a little bit more about this. Does point 8 imply that key
should be released on unlock if it was *not* modified and on commit/
rollback if it was modified?
Precisely. :-)
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
8:56 a.m.
On 5/19/09 12:00 PM, Manik Surtani wrote:
> Thought a little bit more about this. Does point 8 imply that key
> should be released on unlock if it was *not* modified and on
> commit/rollback if it was modified?
Precisely. :-)
How do we determine if a node was modified during some transaction? I am
asking because the entry I lookup from IC during unlock call (and before
commit) always returns true for CacheEntry#isChanged, even if node was
not accessed during tx.
If I lookup modifications through TxInvocationContext I do get correct
modifications but here we are dealing with WriteCommands who do not have
API to access key. So I have to check if WriteCommand is an instance of
DataCommand....
My point is - there must be a better way to check for modifications that
I cannot find in API :(
9:22 a.m.
On 19 May 2009, at 14:56, Vladimir Blagojevic wrote:
On 5/19/09 12:00 PM, Manik Surtani wrote:
>> Thought a little bit more about this. Does point 8 imply that key
>> should be released on unlock if it was *not* modified and on
>> commit/rollback if it was modified?
>
> Precisely. :-)
>
How do we determine if a node
^^ You mean entry? :-)
was modified during some transaction? I am asking because the entry
I lookup from IC during unlock call (and before commit) always
returns true for CacheEntry#isChanged, even if node was not accessed
during tx.
Yes, that's because the Lock command would have put it there.
If I lookup modifications through TxInvocationContext I do get
correct modifications but here we are dealing with WriteCommands who
do not have API to access key. So I have to check if WriteCommand is
an instance of DataCommand....
My point is - there must be a better way to check for modifications
that I cannot find in API :(
Yes, this is how you would have to do it - for now at least. Hmm -
how else could we improve this - perhaps maintain a set of keys
modified in the transaction context, so that every time a WriteCommand
completes within a transaction, its keys are added to this set?
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
12:20 p.m.
Manik Surtani wrote:
On 19 May 2009, at 09:41, Vladimir Blagojevic wrote:
> On 5/19/09 9:33 AM, Vladimir Blagojevic wrote:
>>> 8. Test that locks are NOT released despite unlock if the key is
>>> modified in the tx. Should only unlock on commit/rollback in this
>>> case.
>>>
>> I finished all tests except 8. I am confused with implied semantic of
>> unlock. What is the point of having unlock then? If we are allowing
>> locking with transactions only why do we need unlock?
>>
> Thought a little bit more about this. Does point 8 imply that key
> should be released on unlock if it was *not* modified and on
> commit/rollback if it was modified?
Precisely. :-)
IMO these semantics going to be badly misused. I can already see people
doing:
lock(k1);
int count = get(k1)
put(k2, count);
unlock(k1);
commit; // Count might have changed!
--
Jason T. Greene
JBoss, a division of Red Hat
12:29 p.m.
Jason T. Greene wrote:
Manik Surtani wrote:
>
> On 19 May 2009, at 09:41, Vladimir Blagojevic wrote:
>
>> On 5/19/09 9:33 AM, Vladimir Blagojevic wrote:
>>>> 8. Test that locks are NOT released despite unlock if the key is
>>>> modified in the tx. Should only unlock on commit/rollback in this
>>>> case.
>>>>
>>> I finished all tests except 8. I am confused with implied semantic
>>> of unlock. What is the point of having unlock then? If we are
>>> allowing locking with transactions only why do we need unlock?
>>>
>> Thought a little bit more about this. Does point 8 imply that key
>> should be released on unlock if it was *not* modified and on
>> commit/rollback if it was modified?
>
> Precisely. :-)
IMO these semantics going to be badly misused. I can already see people
doing:
lock(k1);
int count = get(k1)
put(k2, count);
unlock(k1);
commit; // Count might have changed!
In other words, when using unlock with transactions, it is either a
no-op, or it's wrong. IMO you guys should kill it ;)
--
Jason T. Greene
JBoss, a division of Red Hat
6:55 a.m.
On 19 May 2009, at 23:36, Vladimir Blagojevic wrote:
On 5/19/09 7:29 PM, Jason T. Greene wrote:
>
> In other words, when using unlock with transactions, it is either a
> no-op, or it's wrong. IMO you guys should kill it ;)
>
You see! I was not the only one confused :)
LOL!
Hmm ... kill unlock() ... and always assume that the tx completion
will clear locks. Makes sense to me. And if anything, makes the API
easier to use.
Ok, let's go with this then.
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
6173
days inactive
6181
days old
infinispan-dev@lists.jboss.org
11 comments
3 participants
participants (3)
-
Jason T. Greene -
Manik Surtani -
Vladimir Blagojevic