More operations after a lock
Hi all,
I'm implementing a little test case for a session manager using couchbase as the external repository. Very briefly my idea is to implement the following flow:
1.- Session id is passed (if it's a new session it's added to couchbase).
2.- Session is locked (getAndLock)
3.- Session is managed by the user (read, modify or delete is possible).
4.- If session is modified => cas (session is saved, touched and unlocked)
5.- If session is not modified (just accessed) => touch and unlock (exp time is needed)
6.- If session is deleted => unlock and delete
My problem is in case (5) and (6) two calls are needed, in (5) you need to touch and then unlock and in (6) unlock and then delete. I want to minimize the number of couchbase calls per request so... Is it possible to have a touchAndUnlock and a delete with cas? The one that disturbs me more is case (5), cos delete seems less frequent.
I don't know if I'm saying a nonsense, but I think it'd be nice if after a lock several operations could be performed (right now there's only two possibilities cas or unlock). This is just an idea.
I wasn't sure to post here on in feature request queue.
Thanks!
Sorry but I don't agree with that. Usual non sticky sessions have to guarantee the access from only one server while locked (non-sticky means that http requests are balanced between several servers). For example AJAX or other JavaScript accesses can happen at parallel (or very parallel at least) from the same client and the session has to be locked while one server is attending the request to prevent changes from the others (errors are not acceptable).
But it doesn't matter, the final reason of this post is that there are some lack of methods after a lock (if locking is being intensively used more actions than unlock or cas are possible).
A better and longer explanation of the idea:
http://blogs.nologin.es/rickyepoderi/index.php?/archives/56-Couchbase-Ma...
Thanks!
I don't think you need a lock, as described in step 2. The only reason to lock would be if you wanted to prevent other actors from accessing that data, and then you'd only do it for a short period of time for an update.
A more common approach is simply to write the session manager to handle any CAS failures. That way if one browser closes, and I open another one and get the session back, I can still update it and move on. If, for some odd reason, two people end up associated with the same session, one guy will update with the correct CAS and the other will fail because the client representation of the session is now out of synch. Login message is displayed to that user.