Optimistic Locking

[dnielben]

Hi all!

I am implementing a version of JBCache using optimistic loking, following the indications presented in the forum and in the docs i found in the distribution.

So far I add:
- an aspect to intercept the behavior of findNode(fqn)
- I add an Interceptor to manage creation of nodes in the workspace when a put method is invoked.
- I also add a call interceptor that avoids the chain of interceptors when i am in optimistic mode and i am not preparing or commiting.

Now I have this questions:
1. My first draft design attempt to update all the caches is the clusterm but the one performing the operation, this because prepare and commits avoid self :(. Any clues here?

2. I am not sure if i have to add the nodes that i have to lock to the list of the transaction, so far i am only adding the operations. I hope this will work :(. Is this ok? the documentation talks that they are using for unloking/ abort, the other nodes need this list or they make their own list?

3. This topic seems like dead in the forum..are you using other media to discuss this? a mail list?

Any advice/critic will be apprecited !

Daniel

[dnielben]

Just to follow track and in some one is interested!

> Mr. Bela Ban
>
> Hi!
>
> I have posted this in the forum if you prefer to answer there.
>
> I am implementing a version of JBCache using optimistic locking,
> following the indications presented in the forum and in the docs i found
> in the distribution.
>
> So far I add:
> - an aspect to intercept the behavior of findNode(fqn)
> - I add an Interceptor to manage creation of nodes in the workspace when
> a put method is invoked.
> - I also add a call interceptor that avoids the chain of interceptors
> when i am in optimistic mode and i am not preparing or commiting.



Are you doing this on CVS head, or on 1.2 ?


> Now I have this questions:
> 1. My first draft design attempt to update all the caches is the cluster
> but the one performing the operation, this because prepare and commits
> avoid self :( . Any clues here?



On TX commit ?

> 2. I am not sure if i have to add the nodes that i have to lock to the
> list of the transaction, so far i am only adding the operations. I hope
> this will work :( . Is this ok? the documentation talks that they are
> using for unloking/ abort, the other nodes need this list or they make
> their own list?

> Mr. Bela Ban
>
> Hi!
>
> I have posted this in the forum if you prefer to answer there.
>
> I am implementing a version of JBCache using optimistic locking,
> following the indications presented in the forum and in the docs i found
> in the distribution.
>
> So far I add:
> - an aspect to intercept the behavior of findNode(fqn)
> - I add an Interceptor to manage creation of nodes in the workspace when
> a put method is invoked.
> - I also add a call interceptor that avoids the chain of interceptors
> when i am in optimistic mode and i am not preparing or commiting.



Are you doing this on CVS head, or on 1.2 ?


> Now I have this questions:
> 1. My first draft design attempt to update all the caches is the cluster
> but the one performing the operation, this because prepare and commits
> avoid self :( . Any clues here?



On TX commit ?

> 2. I am not sure if i have to add the nodes that i have to lock to the
> list of the transaction, so far i am only adding the operations. I hope
> this will work :( . Is this ok? the documentation talks that they are
> using for unloking/ abort, the other nodes need this list or they make
> their own list?



Don't know, this is your design decision

> 3. This topic seems like dead in the forum..are you using other media to
> discuss this? a mail list?



No, the forum (JBossCache) is the right place.

Do you have any design documents regarding this ?

Don't know, this is your design decision

> 3. This topic seems like dead in the forum..are you using other media to
> discuss this? a mail list?



No, the forum (JBossCache) is the right place.

Do you have any design documents regarding this ?

[dnielben]

Hi !

thanks for your answer !

Are you doing this on CVS head, or on 1.2 ?

I am using cvs head, It was hard to download the cvs file, are the sources included in the distribution? i download that version but there are no sources there!.

> Now I have this questions:
> 1. My first draft design attempt to update all the caches is the cluster
> but the one performing the operation, this because prepare and commits
> avoid self :( . Any clues here?


you wrote: On TX commit ?

Yes.

My design idea is to intercept the calls before the chain and skip it if the process is taking place (active)*. When I go directly to the methods in cache, I have an aspect to intercept the calls to findNode(fqn), this aspect will answer with the version in the workspace.** Once the system try to prepare or commit i will use the system with out modification(using the chain).

* I also check: if the node needs to be created in the work space(new node && put method), I modify the transaction table with CRUD opps.
** It will read a copy from the actual cache, if it does not have one!

The problem is that as i have not modified my current cache, i should tell it to apply the transaction but the commit and prepare methods skip self.

I am missing something here?


you wrote: Do you have any design documents regarding this ?

Not yet. I am doing my draft design . But so far i Have:

Things to refactor in aspects:
1. I destructively modify:
- Node: I make it implements Versionable(my own interface).
- Entry: I add a Map as a work space (ouch.. i said is a draft).
- I modify cache to add my new interceptor.

Aspects:
- FindFqnAspect. To intercept calls when i am using optimistic locks.
- NodeVersionAspect manage versioning, it has to know when to change a version and when not to do it.

Regards
Daniel.