struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Meadors <lmead...@apache.org>
Subject Re: Record locking
Date Tue, 01 Nov 2005 22:18:49 GMT
I agree with Jason's assertion 100%.

Your best bet on the web is record versioning.

Larry


On 11/1/05, Jason King <jhking@airmail.net> wrote:
> This isn't a struts question so much as a persistence layer question.
> There are several approaches you can use depending on your data and your
> users.
> For infrequently updated tables you can hope for the best and probably
> be safe.
> If you're in an EJB world the EBJ layer takes care of that (I think).
> If you're using JDBC you can:
> a) implement a last_updated column and a trigger to populate it in your
> tables (assuming the db supports it) and only do an update if the
> current last_updated matches the one with the new values (that means
> user b errors out).  He won't be thrilled, but you'll have no lost updates.
> b)  Save old values (possibly in a session-level object) and only
> perform the update if all the current row values match the saved ones
> from the session.  This works for trigger-impaired databases, but also
> causes User B to get an error message.
> Using Ibatis a similar approach to raw JDBC should work.  Never having
> used Hibernate I can't tell you if it has any provisions to avoid the
> "lost update" problem you described.  I can fairly confidently state
> that you won't be able to solve the problem via record-locking.  Given
> the largely stateless nature of web applications and the likelyhood of
> connections dropping, you'd be setting yourself up for hell if you tried
> to maintain a database transaction across multiple submits.
> Murray Collingwood wrote:
>
> >Hi all
> >
> >As long as I have been on this list I have never heard anybody discuss record locking.
> >The scenario is very simple:
> >
> >1. User A clicks an "edit" option to edit a record.
> >2. While user A is editing the record user B clicks the same "edit" option
> >3. Both users are now editing the same record (or so they think)
> >4. User A clicks "save" and the record is updated and displays the changes made by
> >user A - user A is happy
> >5. User B clicks "save" and these changes overwirte the changes made by user A,
> >however user B doesn't know this and the changes made by user B appear.
> >
> >Sometime later user A realises that the changes made have disappeared and gets
> >angry and begins throwing large objects around the room and making lots of loudish
> >gutteral noises in an attempt to disperse inner emotional anxiety.
> >
> >Well, you get the picture.
> >
> >Q. Does Struts assume that the developer will code in the appropriate record locks
in
> >the database?
> >
> >Q. Does anybody actually do this?
> >
> >Q. How?  What type of record locking do you use?
> >
> >TIA
> >mc
> >
> >FOCUS Computing - web design
> >Mob: 0415 24 26 24
> >murray@focus-computing.com.au
> >http://www.focus-computing.com.au
> >
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message