Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of larry.meadors@gmail.com
 designates 64.233.162.207 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=bre9GdJucnWNXn7pE3ODDJajYd4xlUwmHelwKf0nuVvNCWWUoJo5E94nX6Wlgv6aUGnYhgAnb/tUB6xtnEkJ/eNSWruOmcN+RqcjvXggf8o1iMemdmoz/IxsAC7Psgc03akj3XlxEUdvoHA/5HCTMlJkpz889uJtPt4o2LRSEk4=
Message-ID: <a10a823c0511011418m2e61a17p80adac23f3872a35@mail.gmail.com>
Date: Tue, 1 Nov 2005 15:18:49 -0700
From: Larry Meadors <lmeadors@apache.org>
Reply-To: lmeadors@apache.org
Sender: larry.meadors@gmail.com
To: Struts Users Mailing List <user@struts.apache.org>
Subject: Re: Record locking
In-Reply-To: <4367E96D.6070706@airmail.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <436870F0.22986.86937A@localhost> <4367E96D.6070706@airmail.net>

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 update=
s.
> 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 r=
ecord 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" opti=
on
> >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 chang=
es 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 an=
d 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 re=
cord 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