Locking within a clustered environment

[sbarriba <sb...@yahoo.co.uk>]

Hi all,

We're testing clustering with 2 JackRabbit 1.3 instances - Instance 1 and
Instance 2 using the DatabaseJournal with MySql.

 

I've able to lock node /home/nodeA in instance 1. My expectation is that
attempting to lock this in instance 2 would yield a "Node already locked"
error.

Instead we ARE able to lock /home/nodeA in instance 2 as well. This implies
that 2 users could concurrently modify a node simultaneously which is not
desirable.

 

Am I correct in expecting clustering to propagate lock statuses?

 

Regards,

Shaun.

 

 

Re: Locking within a clustered environment

[Alessandro Bologna <al...@gmail.com>]

About clustering, I remember that when it was introduced, there was  
an option to choose what workspaces and at what time interval should  
be participating in the cluster. I could not find that in the wiki page.
Does anybody know where to look (besides of course the source code),  
or am I mistaken?

Thanks.
Alessandro



On Jul 27, 2007, at 10:18 AM, David Nuescheler wrote:

> Hi Shaun,
>
>> I've able to lock node /home/nodeA in instance 1. My expectation  
>> is that
>> attempting to lock this in instance 2 would yield a "Node already  
>> locked"
>> error.
> If the lock is committed I would expect the same behaviour...
>
>> Instead we ARE able to lock /home/nodeA in instance 2 as well.  
>> This implies
>> that 2 users could concurrently modify a node simultaneously which  
>> is not
>> desirable.
> agreed ;)
>
> The only thing that I could imagine is that transactions are in the  
> way.
>
> It is important to understand that a sequence...
>
> ---
> BeginTransaction
> Lock
> Do Something
> Save
> Unlock
> Commit
> ---
>
> ...can be considered equivalent to...
>
> ---
> BeginTransaction
> Do Something
> Save
> Commit
> ---
>
> ...and therefore is unnecessary overuse of locking.
> Atomicity is guaranteed anyway.
>
> regards,
> david

Re: Locking within a clustered environment

[David Nuescheler <da...@day.com>]

Hi Shaun,

> I've able to lock node /home/nodeA in instance 1. My expectation is that
> attempting to lock this in instance 2 would yield a "Node already locked"
> error.
If the lock is committed I would expect the same behaviour...

> Instead we ARE able to lock /home/nodeA in instance 2 as well. This implies
> that 2 users could concurrently modify a node simultaneously which is not
> desirable.
agreed ;)

The only thing that I could imagine is that transactions are in the way.

It is important to understand that a sequence...

---
BeginTransaction
Lock
Do Something
Save
Unlock
Commit
---

...can be considered equivalent to...

---
BeginTransaction
Do Something
Save
Commit
---

...and therefore is unnecessary overuse of locking.
Atomicity is guaranteed anyway.

regards,
david