[Micronet] [web application dev] best practice for ensuring release of a pessimistic lock ?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[Micronet] [web application dev] best practice for ensuring release of a pessimistic lock ?

Russell Connacher
Hi all,

I've come upon a use case where I need to force a pessimistic lock on a data
record, but since it's a web application I can't rely on a client-based event to
release the lock. (I'm writing an appointment scheduling app, and after
selecting a time slot, the user will enter topics she hopes to discuss before
confirming.)

 From what I can scrape up on the web, this is often handled by spawning a new
thread to act as a timer. If the timer runs all the way down to zero, the
transaction that locked the record is rolled back. A normal submission event
from the client, on the other hand, will notify the timer thread to stop and
complete the transaction successfully.

I already have a javascript-based timer on the web view that forces a submit and
roll-back after a reasonable period of inactivity, so I suppose I'd set the
server-side timer thread to run just a bit longer than that.

Any views on this? Any better ideas?

thanks!
Russ

(my app is a java servlet running in Tomcat, based in Spring Webflow 2)

--

Russell Connacher                   113 Campbell Hall # 2924
Information Systems                 Berkeley, CA 94720-2924
Undergraduate Advising              (510)643-9892, 642-2372(FAX)
College of Letters & Science, UCB   [hidden email]

(please consider the environment before printing this email)

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] [web application dev] best practice for ensuring release of a pessimistic lock ?

Steven Hansen

Is there are reason why you can't use a optimistic lock with version
numbers?'

~Steven


Russell Connacher wrote:

> Hi all,
>
> I've come upon a use case where I need to force a pessimistic lock on a data
> record, but since it's a web application I can't rely on a client-based event to
> release the lock. (I'm writing an appointment scheduling app, and after
> selecting a time slot, the user will enter topics she hopes to discuss before
> confirming.)
>
>  From what I can scrape up on the web, this is often handled by spawning a new
> thread to act as a timer. If the timer runs all the way down to zero, the
> transaction that locked the record is rolled back. A normal submission event
> from the client, on the other hand, will notify the timer thread to stop and
> complete the transaction successfully.
>
> I already have a javascript-based timer on the web view that forces a submit and
> roll-back after a reasonable period of inactivity, so I suppose I'd set the
> server-side timer thread to run just a bit longer than that.
>
> Any views on this? Any better ideas?
>
> thanks!
> Russ
>
> (my app is a java servlet running in Tomcat, based in Spring Webflow 2)
>
>  


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] [web application dev] best practice for ensuring release of a pessimistic lock ?

Russell Connacher
Believe me, Steven, I'd prefer that method.

However, we want to guarantee to users that once they select a time slot, it's
theirs until they let go of it. We run out every day, meaning there's always a
fight for those last few available slots.

Steven Hansen wrote:

> Is there are reason why you can't use a optimistic lock with version
> numbers?
>
>> I've come upon a use case where I need to force a pessimistic lock on
>> a data record, but since it's a web application I can't rely on a
>> client-based event to release the lock. (I'm writing an appointment
>> scheduling app, and after selecting a time slot, the user will enter
>> topics she hopes to discuss before confirming.)
>>
>> From what I can scrape up on the web, this is often handled by
>> spawning a new thread to act as a timer. If the timer runs all the way
>> down to zero, the transaction that locked the record is rolled back. A
>> normal submission event from the client, on the other hand, will
>> notify the timer thread to stop and complete the transaction
>> successfully.
>>
>> I already have a javascript-based timer on the web view that forces a
>> submit and roll-back after a reasonable period of inactivity, so I
>> suppose I'd set the server-side timer thread to run just a bit longer
>> than that.
>>
>> Any views on this? Any better ideas?
>>
>> (my app is a java servlet running in Tomcat, based in Spring Webflow 2)

--

Russell Connacher                   113 Campbell Hall # 2924
Information Systems                 Berkeley, CA 94720-2924
Undergraduate Advising              (510)643-9892, 642-2372(FAX)
College of Letters & Science, UCB   [hidden email]

(please consider the environment before printing this email)

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] [web application dev] best practice for ensuring release of a pessimistic lock ?

Steven Hansen
Russell Connacher wrote:
> Believe me, Steven, I'd prefer that method.
>
> However, we want to guarantee to users that once they select a time slot, it's
> theirs until they let go of it. We run out every day, meaning there's always a
> fight for those last few available slots.
>  
Just curious, what has to happen for a user to "let go" of a time slot?  
Does a timeout, such as you
mention below, imply that the user has "let go" of their slot?

~Steven

> Steven Hansen wrote:
>  
>> Is there are reason why you can't use a optimistic lock with version
>> numbers?
>>
>>    
>>> I've come upon a use case where I need to force a pessimistic lock on
>>> a data record, but since it's a web application I can't rely on a
>>> client-based event to release the lock. (I'm writing an appointment
>>> scheduling app, and after selecting a time slot, the user will enter
>>> topics she hopes to discuss before confirming.)
>>>
>>> From what I can scrape up on the web, this is often handled by
>>> spawning a new thread to act as a timer. If the timer runs all the way
>>> down to zero, the transaction that locked the record is rolled back. A
>>> normal submission event from the client, on the other hand, will
>>> notify the timer thread to stop and complete the transaction
>>> successfully.
>>>
>>> I already have a javascript-based timer on the web view that forces a
>>> submit and roll-back after a reasonable period of inactivity, so I
>>> suppose I'd set the server-side timer thread to run just a bit longer
>>> than that.
>>>
>>> Any views on this? Any better ideas?
>>>
>>> (my app is a java servlet running in Tomcat, based in Spring Webflow 2)
>>>      
>
>  


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] [web application dev] best practice for ensuring release of a pessimistic lock ?

John Keller
In reply to this post by Russell Connacher
My approach would be to concoct some solution that does not require a
database lock.

For example, set a timestamp field on the record when it is "claimed".  
Allow other users to "claim" records that either do not have a timestamp
or have a timestamp that is more than X minutes old (meaning the
original user did not "confirm" within the required time limit).  
If/when the original user "confirms", update the record in some way to
indicate it is not available no matter what the timestamp says.

- john



On 6/22/2010 11:36 AM, Russell Connacher wrote:

> Hi all,
>
> I've come upon a use case where I need to force a pessimistic lock on a data
> record, but since it's a web application I can't rely on a client-based event to
> release the lock. (I'm writing an appointment scheduling app, and after
> selecting a time slot, the user will enter topics she hopes to discuss before
> confirming.)
>
>   From what I can scrape up on the web, this is often handled by spawning a new
> thread to act as a timer. If the timer runs all the way down to zero, the
> transaction that locked the record is rolled back. A normal submission event
> from the client, on the other hand, will notify the timer thread to stop and
> complete the transaction successfully.
>
> I already have a javascript-based timer on the web view that forces a submit and
> roll-back after a reasonable period of inactivity, so I suppose I'd set the
> server-side timer thread to run just a bit longer than that.
>
> Any views on this? Any better ideas?
>
> thanks!
> Russ
>
> (my app is a java servlet running in Tomcat, based in Spring Webflow 2)
>
>    

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] [web application dev] best practice for ensuring release of a pessimistic lock ?

Russell Connacher
In reply to this post by Steven Hansen
Yes, by "let go" I mean the client (user or script) submits some event:

A time slot has three possible states: open, locked, and filled.
1) Open slots are presented to the user, who selects one.
2) The selected slot is marked as locked.
3) The user enters additional information.

4a) The user submits "confirm."
5b) The selected slot is marked as filled.
     (success)

4b) The user submits "cancel."
5b) The selected slot is marked as open.
     (flow returns to #1)

4c) The user does nothing
5c) Javascript submits "cancel" when timeout is reached
6c) The selected slot is marked as open.
     (flow returns to #1)

4d) The user navigates away or closes browser
5d) ??? < < < < <  herein lies the problem < < < < <
6d) The selected slot is marked as open.

Steven Hansen wrote:

>> Believe me, Steven, I'd prefer that method.
>>
>> However, we want to guarantee to users that once they select a time
>> slot, it's theirs until they let go of it. We run out every day,
>> meaning there's always a fight for those last few available slots.
>>  
> Just curious, what has to happen for a user to "let go" of a time slot?  
> Does a timeout, such as you mention below, imply that the user has
> "let go" of their slot?
>
>> Steven Hansen wrote:
>>  
>>> Is there are reason why you can't use a optimistic lock with version
>>> numbers?
>>>
>>>> I've come upon a use case where I need to force a pessimistic lock
>>>> on a data record, but since it's a web application I can't rely on a
>>>> client-based event to release the lock. (I'm writing an appointment
>>>> scheduling app, and after selecting a time slot, the user will enter
>>>> topics she hopes to discuss before confirming.)
>>>>
>>>> From what I can scrape up on the web, this is often handled by
>>>> spawning a new thread to act as a timer. If the timer runs all the
>>>> way down to zero, the transaction that locked the record is rolled
>>>> back. A normal submission event from the client, on the other hand,
>>>> will notify the timer thread to stop and complete the transaction
>>>> successfully.
>>>>
>>>> I already have a javascript-based timer on the web view that forces
>>>> a submit and roll-back after a reasonable period of inactivity, so I
>>>> suppose I'd set the server-side timer thread to run just a bit
>>>> longer than that.
>>>>
>>>> Any views on this? Any better ideas?
>>>>
>>>> (my app is a java servlet running in Tomcat, based in Spring Webflow 2)
>>>>      
>>
>>  
>

--

Russell Connacher                   113 Campbell Hall # 2924
Information Systems                 Berkeley, CA 94720-2924
Undergraduate Advising              (510)643-9892, 642-2372(FAX)
College of Letters & Science, UCB   [hidden email]

(please consider the environment before printing this email)

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] [web application dev] best practice for ensuring release of a pessimistic lock ?

Steven Hansen

Incorporating John's idea, why not have the open state determined by a
combination of a timestamp
indicating when the slot was last updated and the slot's current state.

For example, if the slot is marked as "locked" but it hasn't been
updated (filled) in 5 minutes, then
when the next person tries to clam the slot, treat the slot as opened
and give them the lock.




Russell Connacher wrote:

> Yes, by "let go" I mean the client (user or script) submits some event:
>
> A time slot has three possible states: open, locked, and filled.
> 1) Open slots are presented to the user, who selects one.
> 2) The selected slot is marked as locked.
> 3) The user enters additional information.
>
> 4a) The user submits "confirm."
> 5b) The selected slot is marked as filled.
>      (success)
>
> 4b) The user submits "cancel."
> 5b) The selected slot is marked as open.
>      (flow returns to #1)
>
> 4c) The user does nothing
> 5c) Javascript submits "cancel" when timeout is reached
> 6c) The selected slot is marked as open.
>      (flow returns to #1)
>
> 4d) The user navigates away or closes browser
> 5d) ??? < < < < <  herein lies the problem < < < < <
> 6d) The selected slot is marked as open.
>
> Steven Hansen wrote:
>  
>>> Believe me, Steven, I'd prefer that method.
>>>
>>> However, we want to guarantee to users that once they select a time
>>> slot, it's theirs until they let go of it. We run out every day,
>>> meaning there's always a fight for those last few available slots.
>>>  
>>>      
>> Just curious, what has to happen for a user to "let go" of a time slot?  
>> Does a timeout, such as you mention below, imply that the user has
>> "let go" of their slot?
>>
>>    
>>> Steven Hansen wrote:
>>>  
>>>      
>>>> Is there are reason why you can't use a optimistic lock with version
>>>> numbers?
>>>>
>>>>        
>>>>> I've come upon a use case where I need to force a pessimistic lock
>>>>> on a data record, but since it's a web application I can't rely on a
>>>>> client-based event to release the lock. (I'm writing an appointment
>>>>> scheduling app, and after selecting a time slot, the user will enter
>>>>> topics she hopes to discuss before confirming.)
>>>>>
>>>>> From what I can scrape up on the web, this is often handled by
>>>>> spawning a new thread to act as a timer. If the timer runs all the
>>>>> way down to zero, the transaction that locked the record is rolled
>>>>> back. A normal submission event from the client, on the other hand,
>>>>> will notify the timer thread to stop and complete the transaction
>>>>> successfully.
>>>>>
>>>>> I already have a javascript-based timer on the web view that forces
>>>>> a submit and roll-back after a reasonable period of inactivity, so I
>>>>> suppose I'd set the server-side timer thread to run just a bit
>>>>> longer than that.
>>>>>
>>>>> Any views on this? Any better ideas?
>>>>>
>>>>> (my app is a java servlet running in Tomcat, based in Spring Webflow 2)
>>>>>      
>>>>>          
>>>  
>>>      
>
>  


 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Reply | Threaded
Open this post in threaded view
|

Re: [Micronet] [web application dev] best practice for ensuring release of a pessimistic lock ?

Russell Connacher
In reply to this post by John Keller
Ah yes! now we're on to an idea!

So...

A time slot has an isFilled state and a lastClaimed state

1) Slots matching (isFilled = false) and (lastClaimed < now-n)  are
    presented to the user, who selects one.
2) The selected slot is updated with lastClaimed = now.
3) The user enters additional information.

4a) The user submits "confirm."
5b) The selected slot is marked as isFilled = true
     and optionally lastClaimed = 0,
     (success)

4b) The user submits "cancel."
5b) The selected slot is marked as lastClaimed = 0,
     (flow returns to #1)

4c) The user does nothing
5c) Javascript submits "cancel" when timeout n is reached
6c) The selected slot is marked as lastClaimed = 0.
     (flow returns to #1)

4d) The user navigates away or closes browser
5d) (sound of tumble weeds blowing through ghost town)
6d) After n millisecs, lastClaimed limit will pass,
     thereby including slot in selection at #1
     (no need to clean up "locked" record or lastClaimed state!)

Thanks all!
Russ

Tomo wrote:
> What if your select for the next user was "='open' (or ='locked' and
> timestamp<now()-x) - then you could show "locked" appointments that had been
> given up to subsequent users and have a clean-up later on - e.g. cron job
> that sends email saying "your appointment is still pending" if no one else
> wanted it or send them a "sorry" if you convert their lock to someone
> else's?

Steven Hansen wrote:
> Incorporating John's idea, why not have the open state determined by a
> combination of a timestamp indicating when the slot was last updated and the
> slot's current state.
 >
> For example, if the slot is marked as "locked" but it hasn't been updated
> (filled) in 5 minutes, then when the next person tries to clam the slot,
> treat the slot as opened and give them the lock.

John Keller wrote:
> My approach would be to concoct some solution that does not require a
> database lock.
>
> For example, set a timestamp field on the record when it is "claimed".  
> Allow other users to "claim" records that either do not have a timestamp
> or have a timestamp that is more than X minutes old (meaning the
> original user did not "confirm" within the required time limit).  
> If/when the original user "confirms", update the record in some way to
> indicate it is not available no matter what the timestamp says.

Russell Connacher wrote:

>> I've come upon a use case where I need to force a pessimistic lock on a
>> data record, but since it's a web application I can't rely on a
>> client-based event to release the lock. (I'm writing an appointment
>> scheduling app, and after selecting a time slot, the user will enter topics
>> she hopes to discuss before confirming.)
>>
>> From what I can scrape up on the web, this is often handled by spawning a
>> new thread to act as a timer. If the timer runs all the way down to zero,
>> the transaction that locked the record is rolled back. A normal submission
>> event from the client, on the other hand, will notify the timer thread to
>> stop and complete the transaction successfully.
>>
>> I already have a javascript-based timer on the web view that forces a
>> submit and roll-back after a reasonable period of inactivity, so I suppose
>> I'd set the server-side timer thread to run just a bit longer than that.
>>
>> Any views on this? Any better ideas?
>>
>> (my app is a java servlet running in Tomcat, based in Spring Webflow 2)

--

Russell Connacher                   113 Campbell Hall # 2924
Information Systems                 Berkeley, CA 94720-2924
Undergraduate Advising              (510)643-9892, 642-2372(FAX)
College of Letters & Science, UCB   [hidden email]

(please consider the environment before printing this email)

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet.  This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.