[OT] concurrent updates
pls excuse my struts-[OT] question, but I would appreciate to learn how you handle the situation of concurrent data update within your web applications. think about the following situation: 1. user A fetches customer 007 and displays 007 within his browser 2. user B fetches customer 007 as well and displays 007 within his browser 3. user A updates customer 007 4. user B updates customer 007 as well... How do your systems react? a) the last update wins? b) trying to merge updates of user A and B? c) sending a message to user B that customer 007 was changed since loading, and that user B has to re-enter his update or d) do you have a locking mechanism which prevents this situation - user B has no update button if customer 007 is already in somebody else's update screen or e) ??? thanks for sharing your solutions to this common problem rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] concurrent updates
Very good question on a very difficult topic. This is one of the hardest things in a transactional application. The a-d choices you listed are all possibilities and the one you select depends on your situation/requirements. What does the customer want to happen in this case? This topic is discussed in Martin Fowler's new book Patterns of Enterprise Application Architecture. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 6:41 AM To: [EMAIL PROTECTED] Subject: [OT] concurrent updates pls excuse my struts-[OT] question, but I would appreciate to learn how you handle the situation of concurrent data update within your web applications. think about the following situation: 1. user A fetches customer 007 and displays 007 within his browser 2. user B fetches customer 007 as well and displays 007 within his browser 3. user A updates customer 007 4. user B updates customer 007 as well... How do your systems react? a) the last update wins? b) trying to merge updates of user A and B? c) sending a message to user B that customer 007 was changed since loading, and that user B has to re-enter his update or d) do you have a locking mechanism which prevents this situation - user B has no update button if customer 007 is already in somebody else's update screen or e) ??? thanks for sharing your solutions to this common problem rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] concurrent updates
I guess your choices are: 1. last one wins. 2. Check last modified time in each row before commiting changes. so you have a select before update. there could be more.. anil Jerome Jacobsen wrote: Very good question on a very difficult topic. This is one of the hardest things in a transactional application. The a-d choices you listed are all possibilities and the one you select depends on your situation/requirements. What does the customer want to happen in this case? This topic is discussed in Martin Fowler's new book Patterns of Enterprise Application Architecture. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 6:41 AM To: [EMAIL PROTECTED] Subject: [OT] concurrent updates pls excuse my struts-[OT] question, but I would appreciate to learn how you handle the situation of concurrent data update within your web applications. think about the following situation: 1. user A fetches customer 007 and displays 007 within his browser 2. user B fetches customer 007 as well and displays 007 within his browser 3. user A updates customer 007 4. user B updates customer 007 as well... How do your systems react? a) the last update wins? b) trying to merge updates of user A and B? c) sending a message to user B that customer 007 was changed since loading, and that user B has to re-enter his update or d) do you have a locking mechanism which prevents this situation - user B has no update button if customer 007 is already in somebody else's update screen or e) ??? thanks for sharing your solutions to this common problem rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] concurrent updates
By default the last update would win. Ok for small systems. Any system with multiple editors should at the very least have some auditing columns (in the data table or a separate table) like 'creator', 'modifier', etc. The most common solution to concurrent updates is a 'lockedBy' column, to prevent B from getting an edit screen for 007. The main problem with this approach is stale locks when 'A' doesn't properly log out. The least-effort, honor-system way out of that is to enable anyone to break a lock. 'A' might be mad when she hits 'save' and learns that B has stolen the lock, but it's better than dropping her updates completely. If you don't like the lockedBy column and you are running in only one JVM, you could use a static Hashtable that keeps track of who's got their fingers into what. But you'll still have to deal with stale locks. Anyone out there who has a *general* solution for merging two versions of the same data set is invited to also walk on water and rewrite CVS. :) 'Sending a message' to A or B assumes that you have some push method to contact the user. This could be an applet, or maybe something silly like a 'message' frame that refreshes every 10 seconds. Either way it's a bad hack. The main problem here is that no matter how much we pretend, HTTP is stateless and connectionless. Carlos -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 6:41 AM To: [EMAIL PROTECTED] Subject: [OT] concurrent updates pls excuse my struts-[OT] question, but I would appreciate to learn how you handle the situation of concurrent data update within your web applications. think about the following situation: 1. user A fetches customer 007 and displays 007 within his browser 2. user B fetches customer 007 as well and displays 007 within his browser 3. user A updates customer 007 4. user B updates customer 007 as well... How do your systems react? a) the last update wins? b) trying to merge updates of user A and B? c) sending a message to user B that customer 007 was changed since loading, and that user B has to re-enter his update or d) do you have a locking mechanism which prevents this situation - user B has no update button if customer 007 is already in somebody else's update screen or e) ??? thanks for sharing your solutions to this common problem rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] concurrent updates
I need to do something like this very soon... but haven't given it much thought I'm using Oracle 8i is there a way i query the RDMS for the datestamp when the record was last updated rather than storing it as an extra column in every table From: Anil Amarakoon [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: Re: [OT] concurrent updates Date: Wed, 05 Feb 2003 08:25:14 -0600 I guess your choices are: 1. last one wins. 2. Check last modified time in each row before commiting changes. so you have a select before update. there could be more.. anil Jerome Jacobsen wrote: Very good question on a very difficult topic. This is one of the hardest things in a transactional application. The a-d choices you listed are all possibilities and the one you select depends on your situation/requirements. What does the customer want to happen in this case? This topic is discussed in Martin Fowler's new book Patterns of Enterprise Application Architecture. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 6:41 AM To: [EMAIL PROTECTED] Subject: [OT] concurrent updates pls excuse my struts-[OT] question, but I would appreciate to learn how you handle the situation of concurrent data update within your web applications. think about the following situation: 1. user A fetches customer 007 and displays 007 within his browser 2. user B fetches customer 007 as well and displays 007 within his browser 3. user A updates customer 007 4. user B updates customer 007 as well... How do your systems react? a) the last update wins? b) trying to merge updates of user A and B? c) sending a message to user B that customer 007 was changed since loading, and that user B has to re-enter his update or d) do you have a locking mechanism which prevents this situation - user B has no update button if customer 007 is already in somebody else's update screen or e) ??? thanks for sharing your solutions to this common problem rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] concurrent updates
pls excuse my struts-[OT] question, but I would appreciate to learn how you handle the situation of concurrent data update within your web applications. I have to live with a traditional telnet app which is also updating the files, and I can't hold record locks from the web, so... I read in the record and store a fingerprint of what it looked like when you began editing it. When you to to commit your changes, I re-read the record. If it has changed since you began editing it, you lose. Definitely not ideal, but it works for us. Most of the time I'm writing a new record, so nobody else is going to be editing it while the user is working on filling in the data. -- Wendy Smoak Applications Systems Analyst, Sr. Arizona State University PA Information Resources Management
RE: [OT] concurrent updates
thanks everybody for your feedback I will have a look into the lockedBy column mentioned by Carlos and propably I'll add a column lockedTS (timestamp) and set the validity of the lock to a similar time frame as the session timeout -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Mittwoch, 5. Februar 2003 12:41 To: [EMAIL PROTECTED] Subject: [OT] concurrent updates pls excuse my struts-[OT] question, but I would appreciate to learn how you handle the situation of concurrent data update within your web applications. think about the following situation: 1. user A fetches customer 007 and displays 007 within his browser 2. user B fetches customer 007 as well and displays 007 within his browser 3. user A updates customer 007 4. user B updates customer 007 as well... How do your systems react? a) the last update wins? b) trying to merge updates of user A and B? c) sending a message to user B that customer 007 was changed since loading, and that user B has to re-enter his update or d) do you have a locking mechanism which prevents this situation - user B has no update button if customer 007 is already in somebody else's update screen or e) ??? thanks for sharing your solutions to this common problem rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] concurrent updates
The answer is... what do you want it to be? I You dao updates via reflection does update via the primary key. Last one wins. or II You dao updates via reflection for all the changed fields. Both could win or 2nd one fails. or III Your dao update via reflection for all the fields or via data/time. It fails always if any changes. If you did not understand this, just use choice I. This has nothing to do with patterns, and everything to do with SQL. .V [EMAIL PROTECTED] wrote: pls excuse my struts-[OT] question, but I would appreciate to learn how you handle the situation of concurrent data update within your web applications. think about the following situation: 1. user A fetches customer 007 and displays 007 within his browser 2. user B fetches customer 007 as well and displays 007 within his browser 3. user A updates customer 007 4. user B updates customer 007 as well... How do your systems react? a) the last update wins? b) trying to merge updates of user A and B? c) sending a message to user B that customer 007 was changed since loading, and that user B has to re-enter his update or d) do you have a locking mechanism which prevents this situation - user B has no update button if customer 007 is already in somebody else's update screen or e) ??? thanks for sharing your solutions to this common problem rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] concurrent updates
when user A retrieves data also get a last updated timestamp from table. When you go to update, use that in your where clause. If row not found, someone else changed the row while user A went to get coffee. Automatically refreshing with message in that event would be nice. - or - use a transaciton table to incorporate a checkout scheme, ie, when user goes to modify a customer, add transaction row to check customer out. Anyone else attempting will find it already checked out and will be denied. I've done both in large systems - Original Message - From: Vic Cekvenich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 7:39 PM Subject: Re: [OT] concurrent updates The answer is... what do you want it to be? I You dao updates via reflection does update via the primary key. Last one wins. or II You dao updates via reflection for all the changed fields. Both could win or 2nd one fails. or III Your dao update via reflection for all the fields or via data/time. It fails always if any changes. If you did not understand this, just use choice I. This has nothing to do with patterns, and everything to do with SQL. .V [EMAIL PROTECTED] wrote: pls excuse my struts-[OT] question, but I would appreciate to learn how you handle the situation of concurrent data update within your web applications. think about the following situation: 1. user A fetches customer 007 and displays 007 within his browser 2. user B fetches customer 007 as well and displays 007 within his browser 3. user A updates customer 007 4. user B updates customer 007 as well... How do your systems react? a) the last update wins? b) trying to merge updates of user A and B? c) sending a message to user B that customer 007 was changed since loading, and that user B has to re-enter his update or d) do you have a locking mechanism which prevents this situation - user B has no update button if customer 007 is already in somebody else's update screen or e) ??? thanks for sharing your solutions to this common problem rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] concurrent updates
Hmmm Not sure if you are asking a question or answering an answer. - Locking a row or a leaf page the row is on on a large system should be done only after careful consideration. Performance, Deadly embrace, other apps, user time out, dead sessions, etc. -Refresh of data has to do with row cache you do. Popular one is Poolman, where it needs to time out, but many others out there in use. Again, refresh is typically not done on large systems. (I think you are saying that when a DB changes a row, it should send a message to browsers and make it refresh the rows it's displaying and that you did this? OK if you say so.) If you are experienced SQL and know these topics well, then you can make a choice. Else, if you are not intimate, I suggest optimistic cache approach with a decent cache decay. .V Christopher Willingham wrote: when user A retrieves data also get a last updated timestamp from table. When you go to update, use that in your where clause. If row not found, someone else changed the row while user A went to get coffee. Automatically refreshing with message in that event would be nice. - or - use a transaciton table to incorporate a checkout scheme, ie, when user goes to modify a customer, add transaction row to check customer out. Anyone else attempting will find it already checked out and will be denied. I've done both in large systems - Original Message - From: Vic Cekvenich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 7:39 PM Subject: Re: [OT] concurrent updates The answer is... what do you want it to be? I You dao updates via reflection does update via the primary key. Last one wins. or II You dao updates via reflection for all the changed fields. Both could win or 2nd one fails. or III Your dao update via reflection for all the fields or via data/time. It fails always if any changes. If you did not understand this, just use choice I. This has nothing to do with patterns, and everything to do with SQL. .V [EMAIL PROTECTED] wrote: pls excuse my struts-[OT] question, but I would appreciate to learn how you handle the situation of concurrent data update within your web applications. think about the following situation: 1. user A fetches customer 007 and displays 007 within his browser 2. user B fetches customer 007 as well and displays 007 within his browser 3. user A updates customer 007 4. user B updates customer 007 as well... How do your systems react? a) the last update wins? b) trying to merge updates of user A and B? c) sending a message to user B that customer 007 was changed since loading, and that user B has to re-enter his update or d) do you have a locking mechanism which prevents this situation - user B has no update button if customer 007 is already in somebody else's update screen or e) ??? thanks for sharing your solutions to this common problem rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] concurrent updates
it's an answer. my personal opinion, using timestamps is the easiest and fastest, having done both on many occasions. optimistic style never was acceptable unfortunately. - Original Message - From: Vic Cekvenich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 9:39 PM Subject: Re: [OT] concurrent updates Hmmm Not sure if you are asking a question or answering an answer. - Locking a row or a leaf page the row is on on a large system should be done only after careful consideration. Performance, Deadly embrace, other apps, user time out, dead sessions, etc. -Refresh of data has to do with row cache you do. Popular one is Poolman, where it needs to time out, but many others out there in use. Again, refresh is typically not done on large systems. (I think you are saying that when a DB changes a row, it should send a message to browsers and make it refresh the rows it's displaying and that you did this? OK if you say so.) If you are experienced SQL and know these topics well, then you can make a choice. Else, if you are not intimate, I suggest optimistic cache approach with a decent cache decay. .V Christopher Willingham wrote: when user A retrieves data also get a last updated timestamp from table. When you go to update, use that in your where clause. If row not found, someone else changed the row while user A went to get coffee. Automatically refreshing with message in that event would be nice. - or - use a transaciton table to incorporate a checkout scheme, ie, when user goes to modify a customer, add transaction row to check customer out. Anyone else attempting will find it already checked out and will be denied. I've done both in large systems - Original Message - From: Vic Cekvenich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 7:39 PM Subject: Re: [OT] concurrent updates The answer is... what do you want it to be? I You dao updates via reflection does update via the primary key. Last one wins. or II You dao updates via reflection for all the changed fields. Both could win or 2nd one fails. or III Your dao update via reflection for all the fields or via data/time. It fails always if any changes. If you did not understand this, just use choice I. This has nothing to do with patterns, and everything to do with SQL. .V [EMAIL PROTECTED] wrote: pls excuse my struts-[OT] question, but I would appreciate to learn how you handle the situation of concurrent data update within your web applications. think about the following situation: 1. user A fetches customer 007 and displays 007 within his browser 2. user B fetches customer 007 as well and displays 007 within his browser 3. user A updates customer 007 4. user B updates customer 007 as well... How do your systems react? a) the last update wins? b) trying to merge updates of user A and B? c) sending a message to user B that customer 007 was changed since loading, and that user B has to re-enter his update or d) do you have a locking mechanism which prevents this situation - user B has no update button if customer 007 is already in somebody else's update screen or e) ??? thanks for sharing your solutions to this common problem rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] concurrent updates
We not going any were but I am in a bad mood: - if you are using pessimistic locking, that means that you locked the row, no need for timestamp. - if you are using timestamp, then you are doing optimistic and protecting against dirty writes. .V Christopher Willingham wrote: it's an answer. my personal opinion, using timestamps is the easiest and fastest, having done both on many occasions. optimistic style never was acceptable unfortunately. - Original Message - From: Vic Cekvenich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 9:39 PM Subject: Re: [OT] concurrent updates Hmmm Not sure if you are asking a question or answering an answer. - Locking a row or a leaf page the row is on on a large system should be done only after careful consideration. Performance, Deadly embrace, other apps, user time out, dead sessions, etc. -Refresh of data has to do with row cache you do. Popular one is Poolman, where it needs to time out, but many others out there in use. Again, refresh is typically not done on large systems. (I think you are saying that when a DB changes a row, it should send a message to browsers and make it refresh the rows it's displaying and that you did this? OK if you say so.) If you are experienced SQL and know these topics well, then you can make a choice. Else, if you are not intimate, I suggest optimistic cache approach with a decent cache decay. .V Christopher Willingham wrote: when user A retrieves data also get a last updated timestamp from table. When you go to update, use that in your where clause. If row not found, someone else changed the row while user A went to get coffee. Automatically refreshing with message in that event would be nice. - or - use a transaciton table to incorporate a checkout scheme, ie, when user goes to modify a customer, add transaction row to check customer out. Anyone else attempting will find it already checked out and will be denied. I've done both in large systems - Original Message - From: Vic Cekvenich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 7:39 PM Subject: Re: [OT] concurrent updates The answer is... what do you want it to be? I You dao updates via reflection does update via the primary key. Last one wins. or II You dao updates via reflection for all the changed fields. Both could win or 2nd one fails. or III Your dao update via reflection for all the fields or via data/time. It fails always if any changes. If you did not understand this, just use choice I. This has nothing to do with patterns, and everything to do with SQL. .V [EMAIL PROTECTED] wrote: pls excuse my struts-[OT] question, but I would appreciate to learn how you handle the situation of concurrent data update within your web applications. think about the following situation: 1. user A fetches customer 007 and displays 007 within his browser 2. user B fetches customer 007 as well and displays 007 within his browser 3. user A updates customer 007 4. user B updates customer 007 as well... How do your systems react? a) the last update wins? b) trying to merge updates of user A and B? c) sending a message to user B that customer 007 was changed since loading, and that user B has to re-enter his update or d) do you have a locking mechanism which prevents this situation - user B has no update button if customer 007 is already in somebody else's update screen or e) ??? thanks for sharing your solutions to this common problem rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] concurrent updates
Another alternative to time stamping is auto incrementing a field in the row, so when you check out an object, you set a long value in your object, during an update, ask the DB for its current ID and if it's the same or not. -Bocaj | -Original Message- | From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Vic Cekvenich | Sent: Wednesday, February 05, 2003 9:03 PM | To: [EMAIL PROTECTED] | Subject: Re: [OT] concurrent updates | | We not going any were but I am in a bad mood: | - if you are using pessimistic locking, that means that you locked the | row, no need for timestamp. | - if you are using timestamp, then you are doing optimistic and | protecting against dirty writes. | | .V | | Christopher Willingham wrote: | it's an answer. my personal opinion, using timestamps is the easiest | and | fastest, having done both on many occasions. optimistic style never was | acceptable unfortunately. | | - Original Message - | From: Vic Cekvenich [EMAIL PROTECTED] | To: [EMAIL PROTECTED] | Sent: Wednesday, February 05, 2003 9:39 PM | Subject: Re: [OT] concurrent updates | | | | Hmmm | Not sure if you are asking a question or answering an answer. | | - Locking a row or a leaf page the row is on on a large system should be | done only after careful consideration. Performance, Deadly embrace, | other apps, user time out, dead sessions, etc. | | -Refresh of data has to do with row cache you do. Popular one is | Poolman, where it needs to time out, but many others out there in use. | Again, refresh is typically not done on large systems. | (I think you are saying that when a DB changes a row, it should send a | message to browsers and make it refresh the rows it's displaying and | that you did this? OK if you say so.) | | | If you are experienced SQL and know these topics well, then you can make | a choice. Else, if you are not intimate, I suggest optimistic cache | approach with a decent cache decay. | | .V | | Christopher Willingham wrote: | | when user A retrieves data also get a last updated timestamp from | table. | When you go to update, use that in your where clause. If row not | found, | someone else changed the row while user A went to get coffee. | | Automatically | | refreshing with message in that event would be nice. | | - or - | | use a transaciton table to incorporate a checkout scheme, ie, when user | | goes | | to modify a customer, add transaction row to check customer out. | Anyone | else attempting will find it already checked out and will be denied. | | I've done both in large systems | | - Original Message - | From: Vic Cekvenich [EMAIL PROTECTED] | To: [EMAIL PROTECTED] | Sent: Wednesday, February 05, 2003 7:39 PM | Subject: Re: [OT] concurrent updates | | | | | The answer is... what do you want it to be? | | | I You dao updates via reflection does update via the primary key. | Last one wins. | or | II You dao updates via reflection for all the changed fields. | Both could win or 2nd one fails. | or | III Your dao update via reflection for all the fields or via | data/time. | It fails always if any changes. | | If you did not understand this, just use choice I. This has nothing to | do with patterns, and everything to do with SQL. | | .V | | | | [EMAIL PROTECTED] wrote: | | | pls excuse my struts-[OT] question, but I would appreciate to learn | how | | you | | | handle the situation of concurrent data update within your web | applications. | | think about the following situation: | 1. user A fetches customer 007 and displays 007 within his browser | 2. user B fetches customer 007 as well and displays 007 within his | | browser | | | 3. user A updates customer 007 | 4. user B updates customer 007 as well... | | How do your systems react? | a) the last update wins? | b) trying to merge updates of user A and B? | c) sending a message to user B that customer 007 was changed since | | loading, | | | and that user B has to re-enter his update | or d) do you have a locking mechanism which prevents this situation - | | | user | | | B has no update button if customer 007 is already in somebody | else's | update screen | or e) ??? | | thanks for sharing your solutions to this common problem | rene | | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | | | | | | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] concurrent updates
Right, that's textbook. I meant optimistic as in we'll probably never have a collision, so with such low odds, whoever wins, wins... My clients have never let me get away with that. - Original Message - From: Vic Cekvenich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 10:02 PM Subject: Re: [OT] concurrent updates We not going any were but I am in a bad mood: - if you are using pessimistic locking, that means that you locked the row, no need for timestamp. - if you are using timestamp, then you are doing optimistic and protecting against dirty writes. .V Christopher Willingham wrote: it's an answer. my personal opinion, using timestamps is the easiest and fastest, having done both on many occasions. optimistic style never was acceptable unfortunately. - Original Message - From: Vic Cekvenich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 9:39 PM Subject: Re: [OT] concurrent updates Hmmm Not sure if you are asking a question or answering an answer. - Locking a row or a leaf page the row is on on a large system should be done only after careful consideration. Performance, Deadly embrace, other apps, user time out, dead sessions, etc. -Refresh of data has to do with row cache you do. Popular one is Poolman, where it needs to time out, but many others out there in use. Again, refresh is typically not done on large systems. (I think you are saying that when a DB changes a row, it should send a message to browsers and make it refresh the rows it's displaying and that you did this? OK if you say so.) If you are experienced SQL and know these topics well, then you can make a choice. Else, if you are not intimate, I suggest optimistic cache approach with a decent cache decay. .V Christopher Willingham wrote: when user A retrieves data also get a last updated timestamp from table. When you go to update, use that in your where clause. If row not found, someone else changed the row while user A went to get coffee. Automatically refreshing with message in that event would be nice. - or - use a transaciton table to incorporate a checkout scheme, ie, when user goes to modify a customer, add transaction row to check customer out. Anyone else attempting will find it already checked out and will be denied. I've done both in large systems - Original Message - From: Vic Cekvenich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 7:39 PM Subject: Re: [OT] concurrent updates The answer is... what do you want it to be? I You dao updates via reflection does update via the primary key. Last one wins. or II You dao updates via reflection for all the changed fields. Both could win or 2nd one fails. or III Your dao update via reflection for all the fields or via data/time. It fails always if any changes. If you did not understand this, just use choice I. This has nothing to do with patterns, and everything to do with SQL. .V [EMAIL PROTECTED] wrote: pls excuse my struts-[OT] question, but I would appreciate to learn how you handle the situation of concurrent data update within your web applications. think about the following situation: 1. user A fetches customer 007 and displays 007 within his browser 2. user B fetches customer 007 as well and displays 007 within his browser 3. user A updates customer 007 4. user B updates customer 007 as well... How do your systems react? a) the last update wins? b) trying to merge updates of user A and B? c) sending a message to user B that customer 007 was changed since loading, and that user B has to re-enter his update or d) do you have a locking mechanism which prevents this situation - user B has no update button if customer 007 is already in somebody else's update screen or e) ??? thanks for sharing your solutions to this common problem rene - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
