You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by Alessandro Apostoli <al...@otssistemi.it> on 2004/11/15 19:05:59 UTC
WCK: correct way to interoperate with slide locks
Hi all,
my WCK Slide store implementation has its own locking system,
much simpler than slide's. I can only lock resources either shared
or exclusive only one lock per resource, inheritance is not supported.
When a resource is locked via webdav/WCK everything works
fine for I store the slide lockid passed by lock() and return it when
asked to do so by getLockInfo(). Problems arise when a resource
is locked outside of WCK with a direct call at my API.
In this situation I no longer have a valid lockId to pass back to WCK
and slide complains with a transaction.xa.Exception.
Do I have to create a valid Slide LockNode() and pass its lockId
when needed? What is the correct way of doing all this?
Thanks in advance.
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: WCK: correct way to interoperate with slide locks
Posted by Oliver Zeigermann <ol...@gmail.com>.
Thanks, Alessandro,
I have added this to the Wiki...
Oliver
On Mon, 22 Nov 2004 10:58:16 +0100, Alessandro Apostoli
<al...@otssistemi.it> wrote:
> Hi Oliver,
>
> I made it work on the weekend...
> To summarize things up:
> I have a static Map to hold the lockids to be returned
> by getLockInfo(). Every call to lockObject() generates
> an exclusive lock on my proprietary system and stores
> the pair (uri,lockId) in the map for later retrieval, this for
> webdav locks only.
> Each call to getLockInfo() first checks if there is a lock
> in the proprietary system and if not it returns a SimpleLock[0]
> If the resource is locked it has to determine if it was locked
> via webdav or via proprietary interface so it checks if there's an
> entry in the map for that lock. If so it returns it, if there's no entry
> in the map and the resource is locked it has to generate a valid
> lockId, store it in the map for subsequent calls to getLockInfo()
> and return it. My system supports only one lock per resource so
> the key in my map is the uri, I also used the uri to generate the
> lockId string with a call to DigestUtils.md5Hex(uri).
> As one might expect a call to unlockObject() removes the entry
> from the map and unlocks the resource.
>
> That's all folks
>
> Alessandro.
>
> ---------------------------------------------------------------------
>
>
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: WCK: correct way to interoperate with slide locks
Posted by Alessandro Apostoli <al...@otssistemi.it>.
Hi Oliver,
I made it work on the weekend...
To summarize things up:
I have a static Map to hold the lockids to be returned
by getLockInfo(). Every call to lockObject() generates
an exclusive lock on my proprietary system and stores
the pair (uri,lockId) in the map for later retrieval, this for
webdav locks only.
Each call to getLockInfo() first checks if there is a lock
in the proprietary system and if not it returns a SimpleLock[0]
If the resource is locked it has to determine if it was locked
via webdav or via proprietary interface so it checks if there's an
entry in the map for that lock. If so it returns it, if there's no entry
in the map and the resource is locked it has to generate a valid
lockId, store it in the map for subsequent calls to getLockInfo()
and return it. My system supports only one lock per resource so
the key in my map is the uri, I also used the uri to generate the
lockId string with a call to DigestUtils.md5Hex(uri).
As one might expect a call to unlockObject() removes the entry
from the map and unlocks the resource.
That's all folks
Alessandro.
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: WCK: correct way to interoperate with slide locks
Posted by Oliver Zeigermann <ol...@gmail.com>.
Alessandro,
does it work for you now? If so please share your insight with us :)
Thanks,
Oliver
On Mon, 15 Nov 2004 19:05:59 +0100, Alessandro Apostoli
<al...@otssistemi.it> wrote:
> Hi all,
> my WCK Slide store implementation has its own locking system,
> much simpler than slide's. I can only lock resources either shared
> or exclusive only one lock per resource, inheritance is not supported.
> When a resource is locked via webdav/WCK everything works
> fine for I store the slide lockid passed by lock() and return it when
> asked to do so by getLockInfo(). Problems arise when a resource
> is locked outside of WCK with a direct call at my API.
> In this situation I no longer have a valid lockId to pass back to WCK
> and slide complains with a transaction.xa.Exception.
> Do I have to create a valid Slide LockNode() and pass its lockId
> when needed? What is the correct way of doing all this?
>
> Thanks in advance.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: WCK: correct way to interoperate with slide locks
Posted by Oliver Zeigermann <ol...@gmail.com>.
Hi Alessandro,
(1) This is wrong, do not throw an exception, but return it in
getLockInfo as well, otherwise Slide will think it can acquire such a
lock. This probably is the source of your problem.
(2) I see, you are right.
(3) But you have something like isExclusive in your lock
implementation as well. If a lock is shared of course there can be
more than one lock. However, if you really do not support this, just
set all locks to exclusive when storing them which means there can not
be more than one lock on a resource.
Oliver
On Wed, 17 Nov 2004 17:03:47 +0100, Alessandro Apostoli
<al...@otssistemi.it> wrote:
> Oliver, I should have been more precise:
>
> (1) I do store locks set by webdav in a static Map,
> every call to lockObject() triggers the creation
> of a lock in my proprietary system and stores the
> lockId passed by wck in the map, if a lock already exists
> a SecurityException is raised
> (2) the lockId cannot (should not) be null: 3 cases
> - the resource is not locked
> lockId is null, but i do not return it ;-)
> - the resource has been locked via webdav
> the correct lockId is in the map because it was stored there by
> a previous call to lockObject(), lock details as creator and
> expiration
> are loaded from the proprietary locking system
> - the resource has been locked outside of wck,
> the lockId relative to such an uri is not in the map, i create
> a fake NodeLock, store its lockId in the map and return it
> to wck
> all subsequent calls to getlockInfo get the very same lockId,
> (3) in my current implementation there cannot be more than one lock per
> resource
> if this is a strict webdav requirement I have to completely fake
> it for my system
> does not support it
>
> (4) Caching mode was already set to "cluster" :-(
>
> help!
>
>
>
> >(1) I understand you store locks set by WebDAV as well. Why don't you
> >return them in the getLockInfo? You really should.
> >
> >(2) Sometimes the lockId can be null which certainly is wrong.
> >
> >(3) There can be more than one lock on a resource
> >
> >(4) Maybe your problem is caching. To make all changes in the store
> >come through to Slide immediately you will have to set the caching
> >mode to "cluser". Details at
> >http://wiki.apache.org/jakarta-slide/CacheConfiguration
> >
> >Oliver
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: slide-user-help@jakarta.apache.org
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: WCK: correct way to interoperate with slide locks
Posted by Alessandro Apostoli <al...@otssistemi.it>.
Oliver, I should have been more precise:
(1) I do store locks set by webdav in a static Map,
every call to lockObject() triggers the creation
of a lock in my proprietary system and stores the
lockId passed by wck in the map, if a lock already exists
a SecurityException is raised
(2) the lockId cannot (should not) be null: 3 cases
- the resource is not locked
lockId is null, but i do not return it ;-)
- the resource has been locked via webdav
the correct lockId is in the map because it was stored there by
a previous call to lockObject(), lock details as creator and
expiration
are loaded from the proprietary locking system
- the resource has been locked outside of wck,
the lockId relative to such an uri is not in the map, i create
a fake NodeLock, store its lockId in the map and return it
to wck
all subsequent calls to getlockInfo get the very same lockId,
(3) in my current implementation there cannot be more than one lock per
resource
if this is a strict webdav requirement I have to completely fake
it for my system
does not support it
(4) Caching mode was already set to "cluster" :-(
help!
>(1) I understand you store locks set by WebDAV as well. Why don't you
>return them in the getLockInfo? You really should.
>
>(2) Sometimes the lockId can be null which certainly is wrong.
>
>(3) There can be more than one lock on a resource
>
>(4) Maybe your problem is caching. To make all changes in the store
>come through to Slide immediately you will have to set the caching
>mode to "cluser". Details at
>http://wiki.apache.org/jakarta-slide/CacheConfiguration
>
>Oliver
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: slide-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: WCK: correct way to interoperate with slide locks
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Wed, 17 Nov 2004 14:30:34 +0100, Alessandro Apostoli
<al...@otssistemi.it> wrote:
> Map davLocks = new HashMap();
> ...
> Lock[] getLockInfo(String uri) {
> MyLock myLock = null;
> String lockId = null;
> if ((myLock = getProprietaryLock()) != null) {
> if ((lockId = davLocks.get(uri))==null) {
> // lock created outside of WCK
> lockId = new
> NodeLock(uri,myLock.getSubject(),myLock.getSubject(),myLock.getExpirationTimeAsString(),mylock.isExclusive(),false).getLockId();
> davLocks.put( uri, lockId);
> }
> return new SimpleLock[] { new SimpleLock(lockId, myLock.isExclusive(), false, myLock.getExpirationTime(),
> myLock.getSubject()) };
>
> }
> return new SimpleLock[0];
> }
(1) I understand you store locks set by WebDAV as well. Why don't you
return them in the getLockInfo? You really should.
(2) Sometimes the lockId can be null which certainly is wrong.
(3) There can be more than one lock on a resource
(4) Maybe your problem is caching. To make all changes in the store
come through to Slide immediately you will have to set the caching
mode to "cluser". Details at
http://wiki.apache.org/jakarta-slide/CacheConfiguration
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: WCK: correct way to interoperate with slide locks
Posted by Alessandro Apostoli <al...@otssistemi.it>.
Hi Oliver,
I tried the approach and unfortunately it does not work,
it looks like slide needs to be "internally aware" of the lock.
I need to verify it but I think that a request to wck:lock()
creates an internal reference for the lock in slide.
my pseudo code:
Map davLocks = new HashMap();
...
Lock[] getLockInfo(String uri) {
MyLock myLock = null;
String lockId = null;
if ((myLock = getProprietaryLock()) != null) {
if ((lockId = davLocks.get(uri))==null) {
// lock created outside of WCK
lockId = new
NodeLock(uri,myLock.getSubject(),myLock.getSubject(),myLock.getExpirationTimeAsString(),mylock.isExclusive(),false).getLockId();
davLocks.put( uri, lockId);
}
return new SimpleLock[] { new SimpleLock(lockId, myLock.isExclusive(), false, myLock.getExpirationTime(),
myLock.getSubject()) };
}
return new SimpleLock[0];
}
any ideas??
thanks
Alex.
----- Original Message -----
From: "Oliver Zeigermann" <ol...@gmail.com>
To: "Slide Users Mailing List" <sl...@jakarta.apache.org>
Sent: Monday, November 15, 2004 8:56 PM
Subject: Re: WCK: correct way to interoperate with slide locks
> Hi Alessandro,
>
> this is a very reasonable question! One idea was to allow lockObject
> to throw an already locked exception, but this would be somehow weird
> if getLockInfo did not return any locks. So, short answer: Currently
> the only solution would be to actually fake (create) such a lock
> object. I suspect the Lock interface should be pretty obvious, no? The
> id retrieved with getId is the lock token to identify the lock. AFAIK
> there is no rule how such a token should look like, just make sure the
> association between your internal lock and the token is 1:1.
>
> Creating a NodeLock and getting the generated lock id like in the
> LockMethod is a way to get a lock token, but AFAIK anything else
> should do as well.
>
> Oliver
>
>
> On Mon, 15 Nov 2004 19:05:59 +0100, Alessandro Apostoli
> <al...@otssistemi.it> wrote:
>> Hi all,
>> my WCK Slide store implementation has its own locking system,
>> much simpler than slide's. I can only lock resources either shared
>> or exclusive only one lock per resource, inheritance is not supported.
>> When a resource is locked via webdav/WCK everything works
>> fine for I store the slide lockid passed by lock() and return it when
>> asked to do so by getLockInfo(). Problems arise when a resource
>> is locked outside of WCK with a direct call at my API.
>> In this situation I no longer have a valid lockId to pass back to WCK
>> and slide complains with a transaction.xa.Exception.
>> Do I have to create a valid Slide LockNode() and pass its lockId
>> when needed? What is the correct way of doing all this?
>>
>> Thanks in advance.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: slide-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: WCK: correct way to interoperate with slide locks
Posted by Oliver Zeigermann <ol...@gmail.com>.
Hi Alessandro,
this is a very reasonable question! One idea was to allow lockObject
to throw an already locked exception, but this would be somehow weird
if getLockInfo did not return any locks. So, short answer: Currently
the only solution would be to actually fake (create) such a lock
object. I suspect the Lock interface should be pretty obvious, no? The
id retrieved with getId is the lock token to identify the lock. AFAIK
there is no rule how such a token should look like, just make sure the
association between your internal lock and the token is 1:1.
Creating a NodeLock and getting the generated lock id like in the
LockMethod is a way to get a lock token, but AFAIK anything else
should do as well.
Oliver
On Mon, 15 Nov 2004 19:05:59 +0100, Alessandro Apostoli
<al...@otssistemi.it> wrote:
> Hi all,
> my WCK Slide store implementation has its own locking system,
> much simpler than slide's. I can only lock resources either shared
> or exclusive only one lock per resource, inheritance is not supported.
> When a resource is locked via webdav/WCK everything works
> fine for I store the slide lockid passed by lock() and return it when
> asked to do so by getLockInfo(). Problems arise when a resource
> is locked outside of WCK with a direct call at my API.
> In this situation I no longer have a valid lockId to pass back to WCK
> and slide complains with a transaction.xa.Exception.
> Do I have to create a valid Slide LockNode() and pass its lockId
> when needed? What is the correct way of doing all this?
>
> Thanks in advance.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org