Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Detecting multiple browser windows

 
John Lindwall
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Thanks for any help!
 
Susanta Chatterjee
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi John,

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.

- Susanta
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64967
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How is this different from if different users access and modify the same data sumultaneously? Does your app not have logic to handle this case? It's really no different.

P.S. You may want to google the term "dirty write".
[ March 23, 2005: Message edited by: Bear Bibeault ]
 
Susanta Chatterjee
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agree with Bear. Those two problems are same and the solutions are same too.

- Susanta
 
John Lindwall
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?

Thanks!
 
John Lindwall
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Susanta,

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.

I appreciate your help.
 
Yuriy Zilbergleyt
Ranch Hand
Posts: 429
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?

-Yuriy
 
John Lindwall
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yuriy,

That is inspired! I am certain that your idea will work.

To summarize:

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!

John
 
Yuriy Zilbergleyt
Ranch Hand
Posts: 429
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Good luck!

-Yuriy
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic