Dirty read/edit problem.

[Steve Tarlton <st...@gmail.com>]

I thought I would throw this one out to the user group and see if it makes
sense or am I over complicating things. I am implementing a check list
system using Wicket-Hibernate-Spring. There could potentially be more than
one person trying to edit a given check item within the list and I want to
be sure that two edits against the same check item cannot happen.

I have implemented something like this before using two database tables one
for locking and one for writing who has the lock on a given object. Of
course, that wasn't a web application and it wasn't a client/server
application (well unless you consider the database the server, which is kind
of what I was doing). I would hold on to the transaction for a row id lock
table until the corresponding row that the user was editing was updated this
included the user think time as they had to press a button to edit, which
created this lock table entry as well as a entry in a lock info table that
was committed so that when user b tried to hit edit, it would pull a
transaction isolation exception and then go lookup who had the item locked.

Okay, so I want to implement this same sort of mechanism for check items;
however, because there is a common application-level that everyone connected
shares (I will only have one webserver as opposed to a farm), I was thinking
that I implement a edit-in-progress table as a data source in the
application-layer. Then, when someone clicks the edit button on a selected
check item, I use the edit-in-progress table to make sure someone else isn't
editing the given item. Is this a typical or at least a good approach to
solve such a problem or is there something within Hibernate that I am
unaware of that handles this. I have read about the mult-versioning but how
would you tell the user BEFORE they start to edit something that someone
else has it locked?

Sorry, I know this was a long post but I have to believe that others may
wonder about this kind of user interaction as well and I haven't seen
anything on the topic with the searches I did.

Thanks,
-Steve

Re: Dirty read/edit problem.

[James Carman <jc...@carmanconsulting.com>]

With optimistic locking, there's no real way to know that someone else is
"thinking" about editing something.  As Scott said, I think you want
pessimistic locking.

On Mon, Jun 22, 2009 at 7:24 PM, satar <st...@gmail.com> wrote:

>
> Hum, I may not have a complete understanding of optimistic locking. Bottom
> line is that when someone wants to start editing, I want them to know
> before
> they start if someone else is already in the midths of editing a given
> item.
> I do not want to just hope that two people never edit the same thing and if
> they do error out on the last to try to save if they didn't have the right
> starting version. It seems like that is what could happen in the optimistic
> approach but I could be wrong as I have never used the approach. I will
> study the LockMode.UPGRADE, but if it doesn't give me a way to give user
> feedback when someone else is in edit "thinking" mode, I don't think I
> would
> use it.
> --
> View this message in context:
> http://www.nabble.com/Dirty-read-edit-problem.-tp24157057p24157353.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Dirty read/edit problem.

[James Carman <jc...@carmanconsulting.com>]

The lock "table" is in-memory, so no need to clear on startup.

On Thu, Jun 25, 2009 at 4:36 AM, Adrian Merrall <pi...@gmail.com>wrote:

> You probably also want to use a session listener to clear any left over
> locks when a session is destroyed.  If you are storing the locks in the db
> it would be a good idea to use an app listener to clear the lock table on
> startup.
>
> Adrian,
> Auckland, NZ
>
> On Wed, Jun 24, 2009 at 4:37 AM, satar <st...@gmail.com> wrote:
>
> >
> > Thanks for the responses. I feel a little more confident that there isn't
> > something magical already out there to handle this particular problem
> > domain. I do want pessimistic locking as I want to inform the user that
> > someone else is already thinking and in progress of changing something
> > BEFORE they try to change it themselves, and it is very possible for two
> > peeps to attempt edit on the same item. I am also using mySQL not Oracle
> > and
> > wouldn't probably want to rely on a database specific implementation if I
> > could avoid it. As of now, I have created a lock table in memory at the
> app
> > layer and it sounds like a reasonable approach based on my query from
> > fellow
> > colleges on this forum -- Steve
> > --
> > View this message in context:
> > http://www.nabble.com/Dirty-read-edit-problem.-tp24157057p24167367.html
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>

Re: Dirty read/edit problem.

[Adrian Merrall <pi...@gmail.com>]

You probably also want to use a session listener to clear any left over
locks when a session is destroyed.  If you are storing the locks in the db
it would be a good idea to use an app listener to clear the lock table on
startup.

Adrian,
Auckland, NZ

On Wed, Jun 24, 2009 at 4:37 AM, satar <st...@gmail.com> wrote:

>
> Thanks for the responses. I feel a little more confident that there isn't
> something magical already out there to handle this particular problem
> domain. I do want pessimistic locking as I want to inform the user that
> someone else is already thinking and in progress of changing something
> BEFORE they try to change it themselves, and it is very possible for two
> peeps to attempt edit on the same item. I am also using mySQL not Oracle
> and
> wouldn't probably want to rely on a database specific implementation if I
> could avoid it. As of now, I have created a lock table in memory at the app
> layer and it sounds like a reasonable approach based on my query from
> fellow
> colleges on this forum -- Steve
> --
> View this message in context:
> http://www.nabble.com/Dirty-read-edit-problem.-tp24157057p24167367.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Dirty read/edit problem.

[satar <st...@gmail.com>]

Thanks for the responses. I feel a little more confident that there isn't
something magical already out there to handle this particular problem
domain. I do want pessimistic locking as I want to inform the user that
someone else is already thinking and in progress of changing something
BEFORE they try to change it themselves, and it is very possible for two
peeps to attempt edit on the same item. I am also using mySQL not Oracle and
wouldn't probably want to rely on a database specific implementation if I
could avoid it. As of now, I have created a lock table in memory at the app
layer and it sounds like a reasonable approach based on my query from fellow
colleges on this forum -- Steve
-- 
View this message in context: http://www.nabble.com/Dirty-read-edit-problem.-tp24157057p24167367.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Dirty read/edit problem.

[Scott Swank <sc...@gmail.com>]

On-line docs
http://download-west.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_lock.htm

DA Morgan's docs
http://www.psoug.org/reference/dbms_lock.html

On Tue, Jun 23, 2009 at 12:58 AM, Maarten
Bosteels<mb...@gmail.com> wrote:
> Hi,
>
> We have implemented something similar. In our case multiple applications
> should be able to request locks, so we have implemented it on the database.
> It's based on DBMS_LOCK (Oracle specific).
> When an application crashes (or is killed in an unclean manner) Oracle will
> roll back any pending transactions, and automagically release the locks.
> Works very well (btw, our applications never crash :-)
>
> Since you have only one application, I guess you could do it in the
> application layer (keep locks in memory).
>
> Maarten
>
>
> On Tue, Jun 23, 2009 at 3:07 AM, James Carman
> <jc...@carmanconsulting.com>wrote:
>
>> If it's fairly unlikely that two people would be editing the same record at
>> the same time, then it's probably okay to go with optimistic locking.
>>
>> On Mon, Jun 22, 2009 at 8:41 PM, satar <st...@gmail.com> wrote:
>>
>> >
>> > Yep, that is what I thought from the reading I have done. I think I will
>> do
>> > it the way I have in the past but using an application-level edit table
>> > instead of having to use a database. This feels more natural to me and I
>> > have spent an absorbent amount of time learning Hibernate already and
>> just
>> > hoping that I get some return from all of the complexities it has
>> > eventually. I do believe that will be the case because all you smart
>> peeps
>> > wouldn't be using it if there was nothing to gain. The dirty read problem
>> > seems like such a normal condition for any application that has multiple
>> > writers, so I thought I would see what is a typical approach within web
>> > apps
>> > -- something I am very new at.
>> > --
>> > View this message in context:
>> > http://www.nabble.com/Dirty-read-edit-problem.-tp24157057p24158076.html
>> >   Sent from the Wicket - User mailing list archive at Nabble.com.
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Dirty read/edit problem.

[Maarten Bosteels <mb...@gmail.com>]

Hi,

We have implemented something similar. In our case multiple applications
should be able to request locks, so we have implemented it on the database.
It's based on DBMS_LOCK (Oracle specific).
When an application crashes (or is killed in an unclean manner) Oracle will
roll back any pending transactions, and automagically release the locks.
Works very well (btw, our applications never crash :-)

Since you have only one application, I guess you could do it in the
application layer (keep locks in memory).

Maarten


On Tue, Jun 23, 2009 at 3:07 AM, James Carman
<jc...@carmanconsulting.com>wrote:

> If it's fairly unlikely that two people would be editing the same record at
> the same time, then it's probably okay to go with optimistic locking.
>
> On Mon, Jun 22, 2009 at 8:41 PM, satar <st...@gmail.com> wrote:
>
> >
> > Yep, that is what I thought from the reading I have done. I think I will
> do
> > it the way I have in the past but using an application-level edit table
> > instead of having to use a database. This feels more natural to me and I
> > have spent an absorbent amount of time learning Hibernate already and
> just
> > hoping that I get some return from all of the complexities it has
> > eventually. I do believe that will be the case because all you smart
> peeps
> > wouldn't be using it if there was nothing to gain. The dirty read problem
> > seems like such a normal condition for any application that has multiple
> > writers, so I thought I would see what is a typical approach within web
> > apps
> > -- something I am very new at.
> > --
> > View this message in context:
> > http://www.nabble.com/Dirty-read-edit-problem.-tp24157057p24158076.html
> >   Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>

Re: Dirty read/edit problem.

[James Carman <jc...@carmanconsulting.com>]

If it's fairly unlikely that two people would be editing the same record at
the same time, then it's probably okay to go with optimistic locking.

On Mon, Jun 22, 2009 at 8:41 PM, satar <st...@gmail.com> wrote:

>
> Yep, that is what I thought from the reading I have done. I think I will do
> it the way I have in the past but using an application-level edit table
> instead of having to use a database. This feels more natural to me and I
> have spent an absorbent amount of time learning Hibernate already and just
> hoping that I get some return from all of the complexities it has
> eventually. I do believe that will be the case because all you smart peeps
> wouldn't be using it if there was nothing to gain. The dirty read problem
> seems like such a normal condition for any application that has multiple
> writers, so I thought I would see what is a typical approach within web
> apps
> -- something I am very new at.
> --
> View this message in context:
> http://www.nabble.com/Dirty-read-edit-problem.-tp24157057p24158076.html
>   Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Dirty read/edit problem.

[satar <st...@gmail.com>]

Yep, that is what I thought from the reading I have done. I think I will do
it the way I have in the past but using an application-level edit table
instead of having to use a database. This feels more natural to me and I
have spent an absorbent amount of time learning Hibernate already and just
hoping that I get some return from all of the complexities it has
eventually. I do believe that will be the case because all you smart peeps
wouldn't be using it if there was nothing to gain. The dirty read problem
seems like such a normal condition for any application that has multiple
writers, so I thought I would see what is a typical approach within web apps
-- something I am very new at.
-- 
View this message in context: http://www.nabble.com/Dirty-read-edit-problem.-tp24157057p24158076.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Dirty read/edit problem.

[satar <st...@gmail.com>]

Hum, I may not have a complete understanding of optimistic locking. Bottom
line is that when someone wants to start editing, I want them to know before
they start if someone else is already in the midths of editing a given item.
I do not want to just hope that two people never edit the same thing and if
they do error out on the last to try to save if they didn't have the right
starting version. It seems like that is what could happen in the optimistic
approach but I could be wrong as I have never used the approach. I will
study the LockMode.UPGRADE, but if it doesn't give me a way to give user
feedback when someone else is in edit "thinking" mode, I don't think I would
use it.
-- 
View this message in context: http://www.nabble.com/Dirty-read-edit-problem.-tp24157057p24157353.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Dirty read/edit problem.

[Scott Swank <sc...@gmail.com>]

Why not just lock the relevant row of the relevant table?  Versioning
is for optimistic locking, but it sounds to me like you want plain old
pessimistic locking.

In Hibernate, check out LockMode.UPGRADE.

Scott


On Mon, Jun 22, 2009 at 3:58 PM, Steve Tarlton<st...@gmail.com> wrote:
> I thought I would throw this one out to the user group and see if it makes
> sense or am I over complicating things. I am implementing a check list
> system using Wicket-Hibernate-Spring. There could potentially be more than
> one person trying to edit a given check item within the list and I want to
> be sure that two edits against the same check item cannot happen.
>
> I have implemented something like this before using two database tables one
> for locking and one for writing who has the lock on a given object. Of
> course, that wasn't a web application and it wasn't a client/server
> application (well unless you consider the database the server, which is kind
> of what I was doing). I would hold on to the transaction for a row id lock
> table until the corresponding row that the user was editing was updated this
> included the user think time as they had to press a button to edit, which
> created this lock table entry as well as a entry in a lock info table that
> was committed so that when user b tried to hit edit, it would pull a
> transaction isolation exception and then go lookup who had the item locked.
>
> Okay, so I want to implement this same sort of mechanism for check items;
> however, because there is a common application-level that everyone connected
> shares (I will only have one webserver as opposed to a farm), I was thinking
> that I implement a edit-in-progress table as a data source in the
> application-layer. Then, when someone clicks the edit button on a selected
> check item, I use the edit-in-progress table to make sure someone else isn't
> editing the given item. Is this a typical or at least a good approach to
> solve such a problem or is there something within Hibernate that I am
> unaware of that handles this. I have read about the mult-versioning but how
> would you tell the user BEFORE they start to edit something that someone
> else has it locked?
>
> Sorry, I know this was a long post but I have to believe that others may
> wonder about this kind of user interaction as well and I haven't seen
> anything on the topic with the searches I did.
>
> Thanks,
> -Steve
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org