-
1. Re: Optimistic Locking
dnielben Feb 21, 2005 12:40 PM (in response to 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 ? -
2. Re: Optimistic Locking
dnielben Feb 21, 2005 12:41 PM (in response to 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.