Re: Dirty read/edit problem.
The lock "table" is in-memory, so no need to clear on startup. On Thu, Jun 25, 2009 at 4:36 AM, Adrian Merrall 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 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-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > >
Re: Dirty read/edit problem.
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 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-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Dirty read/edit problem.
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Dirty read/edit problem.
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 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 > 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 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-unsubscr...@wicket.apache.org >> > For additional commands, e-mail: users-h...@wicket.apache.org >> > >> > >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Dirty read/edit problem.
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 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 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-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > >
Re: Dirty read/edit problem.
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 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-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Dirty read/edit problem.
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Dirty read/edit problem.
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 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-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Dirty read/edit problem.
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Dirty read/edit problem.
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 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Dirty read/edit problem.
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