We are seeing some issues in an web application caused by a single user opening mutiple browsers at one time to use the application.
If it matters we can specify the browser to be IE 5+.
Here's the scneario:
1. User accesses a page in our app which loads some data for editing. 2. User edits the data but does not submit the changes yet. 3. User presses Ctrl-N to open a new browser window (containing the same page and context as the original browser window, of course) 4. User edits the data in this new window and submits the changes
The data displayed in the original browser window is stale -- since the user made change stpo it in the new browser window.
is there any way to detect or prevent the users from doing this? I don't see any help in DOM -- there is a uniqueID property but the window object does not support it.
We used a Date object on the server side to resolve this kind of problem. The data which is to be updated has a Date object in it which contains the last modification date. And this date with timestamp is maintained as a hidden field in the html client. Now, when the client side data is submitted, on the server side we capture the date from the hidden field and compare with the date in the database and if the date from request is older than what is in database, we are sure the data in request is stale data and we send the user appropriate error message.
Only downside of this is to maintain an extra timestamp field on the database.
Agree with Bear. Those two problems are same and the solutions are same too.
Joined: May 29, 2002
Thanks for the replies.
Hmm.. In our case I do not think that those are the same problem. Please enlighten me if I'm mistaken.
We use a coopoerative distributed locking mechanism. When a servlet is loading some data for update, it acquires a lock on that data (not a database lock mind you). If another user tries to access that data at the same time the system detects that the data is previously locked and denies access (actually it loads it in a read-only mode). When the user updates (or discards the changes) we release that lock.
The lock mechanism is based on the user's HTTP session, which is really the only thing we have to uniquely identify a user.
What makes my problem case different is that it is the SAME USER with the SAME SESSION ID accessing the data. The locking step has already been performed when the original browser window loaded the data. The "cloned" browser window is opened with a read/write view of that same data and I know of no way to distinguish that there are now two browser winbdows at the time the user updates the data.
I hope I'm being clear. Any thoughts?
Joined: May 29, 2002
Thanks! I think your approach would indeed solve this issue for us.
As you mention it will cost us an additional database field in each table that allows updates.
*** I still wonder though if anyone has any ideas that would solve my problem without requiring such changes? ***
My dream response would be "Oh just use the browserWindowUniqueId to distinguish the user's browser windows from each other" or somesuch.
Do you really need to store the date in the database? Wouldn't storing it in the Session be sufficient for your purposes, if you're only worried about conflicts within a session?
Joined: May 29, 2002
That is inspired! I am certain that your idea will work.
The html contains a hidden field holding the timestamp that the data was loaded. At load time, that same timestamp is also placed in the session.
When the data is submitted for update we compare the timestamps in the hidden field and the session. If they match then the update is allowed to occur and (I suppose) we update the timestamp in the session to the current time.
If the timestamps do not match then that means the user already updated the data in another window and so the update should be rejected.
Does that sound right?
THANK YOU and everyone who replied!
Joined: Dec 13, 2004
Yes, it seems like it would work, just be sure to synchronize on some object (the session or a session-scope object maybe?) when checking and changing the timestamp in the session.
Note that if the data is loaded every time the page is loaded, if the user opens the page in a second window, the first window will no longer be allowed to update since the timestamp has changed. Unless the second window has been opened using a cached version of the page of course.