Locking and concurrency revisited for 2.2

[Oliver Zeigermann <ol...@zeigermann.de>]

Folks!

In the current 2.1 release branch there is a global lock enabled by 
default that allows at most one writing request at a time. This is to 
make explicit the implicit global lock that would have to be set when 
locking the history folder that contains all versioned data.

I see no way to get rid of this global lock without a general redesign 
of versioning. However, if auto-versioning is turned off and the store 
used does not support versioning in the first place - e.g. like the file 
store proposed by Alon - there should be a more suitable locking.

Unfortunately, the exclusive transient locks I introduced with 2.1 are 
not sufficient for this purpose. For 2.2 I would like to remove them 
completely and have read/write locks set and managed by the WebDAV 
layer. Each method would then have to set the oppropriate locks in an 
atomic block before anything else gets done. It is important to do the 
locking in a block before anything else in order to avoid the risk of 
deadlocks. As an example a GET request on /slide/files/olli.doc would 
set read locks on /silde, /silde/files, and /slide/files/olli.doc. A PUT 
on /slide/files/olli.doc would have to wait until the GET is ended and a 
DELETE on /silde/files would have to wait as well. This is the same as 
with the global write lock currently available. However if there is a 
PUT to /slide/files/myfiles/olli.doc this would cause read locks to 
/silde, /silde/files and write locks to /silde/files/myfiles and 
/slide/files/myfiles/olli.doc which would allow for more concurrent read 
requests. E.g. a parallel PUT to /slide/files/yourfiles/olli.doc would 
be possible.

When Slide is accessed over the Slide API this locking would not be 
enabled as well when there are externally controlled transactions 
spanning more than one request.

Such a locking would and addition to stores that do locking of their 
own, but would be even more helpful with stores that do not have locking 
at all like the file store mentioned above.

OK, that's it for now. What do you people think about this? If you agree 
I will implement it. Would be another step to a mature Slide system.

And, yes, sorry for this length post, I have observed my posts get 
lengthy when I do not know for sure what I am talking about. So, be 
careful ;)

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org

Re: Locking and concurrency revisited for 2.2

[James Mason <ma...@apache.org>]

Oliver,
This approach sounds really logical to me :).

-James

Oliver Zeigermann wrote:
> Folks!
> 
> In the current 2.1 release branch there is a global lock enabled by 
> default that allows at most one writing request at a time. This is to 
> make explicit the implicit global lock that would have to be set when 
> locking the history folder that contains all versioned data.
> 
> I see no way to get rid of this global lock without a general redesign 
> of versioning. However, if auto-versioning is turned off and the store 
> used does not support versioning in the first place - e.g. like the file 
> store proposed by Alon - there should be a more suitable locking.
> 
> Unfortunately, the exclusive transient locks I introduced with 2.1 are 
> not sufficient for this purpose. For 2.2 I would like to remove them 
> completely and have read/write locks set and managed by the WebDAV 
> layer. Each method would then have to set the oppropriate locks in an 
> atomic block before anything else gets done. It is important to do the 
> locking in a block before anything else in order to avoid the risk of 
> deadlocks. As an example a GET request on /slide/files/olli.doc would 
> set read locks on /silde, /silde/files, and /slide/files/olli.doc. A PUT 
> on /slide/files/olli.doc would have to wait until the GET is ended and a 
> DELETE on /silde/files would have to wait as well. This is the same as 
> with the global write lock currently available. However if there is a 
> PUT to /slide/files/myfiles/olli.doc this would cause read locks to 
> /silde, /silde/files and write locks to /silde/files/myfiles and 
> /slide/files/myfiles/olli.doc which would allow for more concurrent read 
> requests. E.g. a parallel PUT to /slide/files/yourfiles/olli.doc would 
> be possible.
> 
> When Slide is accessed over the Slide API this locking would not be 
> enabled as well when there are externally controlled transactions 
> spanning more than one request.
> 
> Such a locking would and addition to stores that do locking of their 
> own, but would be even more helpful with stores that do not have locking 
> at all like the file store mentioned above.
> 
> OK, that's it for now. What do you people think about this? If you agree 
> I will implement it. Would be another step to a mature Slide system.
> 
> And, yes, sorry for this length post, I have observed my posts get 
> lengthy when I do not know for sure what I am talking about. So, be 
> careful ;)
> 
> Oliver
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org