db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ramesh Sabeti" ...@reazon.com>
Subject RE: why does Torque select all the data of an object prior to a save ( update )
Date Wed, 03 Dec 2003 18:01:26 GMT
Giulio,

> For sure Torque does a SELECT before an UPDATE to check if records are
> changed...
> I don't think it uses that SELECT to do a record count, because that's
not
> needed... The UPDATE statament already specifies WHERE clauses...

Sorry I misspoke.  It doesn't get a record count, it gets all the
records that are going to be affected, then it does an individual UPDATE
on each record.

> We are using both DB2 and SQLServer, and everything seems fine right
now
> (only Oracle has problems with that "feature" ?)... 

Yes, it affects Oracle more than others.  And the consequences can bring
down the database server to its knees.

> I think we may have a clue on what's happening on "doUpdate" (save()
too)
> looking at Village.

If you find anything that can help, please keep me posted.

Thanks,

Ramesh.

> 
> 
> 
> Giulio Vezzelli
> Infolog S.r.l.
> Via Alfieri, 28
> Modena - 41100
> Telefono : +39-059-822446
> Sito web : http://www.infolog.it
> E-mail : giulio.vezzelli@infolog.it
> 
> 
> 
> > -----Messaggio originale-----
> > Da: Ramesh Sabeti [mailto:rs@reazon.com]
> > Inviato: mercoledì 3 dicembre 2003 18.09
> > A: 'Apache Torque Users List'
> > Oggetto: RE: why does Torque select all the data of an object
> > prior to a save ( update )
> >
> > There shouldn't be a record lock from the time a record is
> > SELECTed by the user for modification to the time the user
> > submits changes.  That's pretty hard to manage in a web app.
> >
> > Here's a pure speculation...  take it with a grain of salt:
> >
> > We know that noot all UPDATEs use the primary key as the
> > identifier, and not all of them update a single record.  So I
> > think torque does a SELECT before an UPDATE to: (1) get a
> > record count, and (2) make sure each record is changed and
> > needs an update.
> >
> > Why is Torque doing it this way is beyond me...  I'm sure
> > there's a good reason behind it.
> >
> > The problem I have is the fact that the SELECT statement
> > issued right before UPDATE is a literal statement as oppose
> > to a prepared statement, and that's problematic with Oracle.
> >
> > Ramesh.
> >
> > > -----Original Message-----
> > > From: Giulio Vezzelli [mailto:giulio.vezzelli@infolog.it]
> > > Sent: Wednesday, December 03, 2003 6:20 AM
> > > To: Apache Torque Users List
> > > Subject: R: why does Torque select all the data of an
> > object prior to
> > a
> > > save ( update )
> > >
> > > You're absolutely right.
> > >
> > > The lock theory I was talking about, though, is the
> > "optimistic" way:
> > >
> > > 17:25 : Guy-A selects record 1. Guy-B selects record 1.
> > >
> > > At 17:30 Guy-A saves record 1, and at 17:35 Guy-B saves record 1.
> > >
> > > When Guy-B saves, the persistency layer should check if
> > record 1 has
> > > changed since it was selected.
> > > If it has changed, the save is ABORTED.
> > >
> > > Guy-B then can't save, because the record has changed.
> > >
> > >
> > > This way the table is never "locked", but still data is checked on
> > update
> > > time.
> > > This is how another persistency layer I know of works.
> > >
> > >
> > > I don't know at all how Torque (better, Village?) handles
> > locking and
> > > concurrency, and I'd like someone to explain me.
> > >
> > >
> > >
> > >
> > >
> > > Giulio Vezzelli
> > > Infolog S.r.l.
> > > Via Alfieri, 28
> > > Modena - 41100
> > > Telefono : +39-059-822446
> > > Sito web : http://www.infolog.it
> > > E-mail : giulio.vezzelli@infolog.it
> > >
> > >
> > >
> > > > -----Messaggio originale-----
> > > > Da: Ashley Hayes [mailto:ashley.hayes@macalla.com]
> > > > Inviato: mercoledì 3 dicembre 2003 14.53
> > > > A: 'Apache Torque Users List'
> > > > Oggetto: RE: why does Torque select all the data of an
> > object prior
> > > > to a save ( update )
> > > >
> > > > Thanks for your input Giulio. I don't see how that locking could
> > > > help. It would just lock the table for the time between
> > the save's
> > > > Select and Update as opposed to from the population to save time
> > > >
> > > > An initial select populates your object from the DB, you may
then
> > > > update as the object as you wish and WAIT an arbitrary amount of
> > > > time before you save the object back to the DB, only at
> > this point
> > > > does the second select occur.
> > > > Even if this causing locking on the table, I don't see
> > the benefit,
> > > > as the potential for a LOST WRITE still exists,e.g.
> > > >
> > > > -------------------------- Time
> > > > ---------------------------------------------------->
> > > > Thread 1:  Query object1
> > > >        Update
> > > > object1
> > > > Thread 2:
> > > >
> > > >               Query object1      Update object1
> > > >
> > > > when Thread1 performs the update the object's table may
> > get locked
> > > > by the SELECT and UPDATE but it still succeeds in
> > updating the data.
> > > >
> > > > so if the second select is only locking at update time,
> > why do it at
> > > > all?
> > > > Am I missing something?
> > > > A
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Giulio Vezzelli [mailto:giulio.vezzelli@infolog.it]
> > > > Sent: 03 December 2003 13:06
> > > > To: Apache Torque Users List
> > > > Subject: R: why does Torque select all the data of an
> > object prior
> > > > to a save ( update )
> > > >
> > > >
> > > > I think Torque selects all data before saving to handle locking.
> > > >
> > > > E.G. It makes sure that the data hasn't changed in the
> > time between
> > > > the moment the business object was populated and the
> > moment you ask
> > > > to save... I suppose...
> > > >
> > > > Giulio Vezzelli
> > > > Infolog S.r.l.
> > > > Via Alfieri, 28
> > > > Modena - 41100
> > > > Telefono : +39-059-822446
> > > > Sito web : http://www.infolog.it
> > > > E-mail : giulio.vezzelli@infolog.it
> > > >
> > > >
> > > >
> > > > > -----Messaggio originale-----
> > > > > Da: Ramesh Sabeti [mailto:rs@reazon.com]
> > > > > Inviato: martedì 2 dicembre 2003 0.11
> > > > > A: 'Apache Torque Users List'
> > > > > Oggetto: RE: why does Torque select all the data of an object
> > > > > prior to a save ( update )
> > > > >
> > > > > Ashley,
> > > > >
> > > > > Did you find an answer to your question, or find a solution?
> > > > > I'm running into the same problem.  It's crashing the Oracle
> > > > > server after a few days of use.
> > > > >
> > > > > Ramesh.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ashley Hayes [mailto:ashley.hayes@macalla.com]
> > > > > > Sent: Friday, October 17, 2003 3:15 AM
> > > > > > To: Torque-User (E-mail)
> > > > > > Subject: why does Torque select all the data of an object
> > > > prior to a
> > > > > save
> > > > > > ( update )
> > > > > >
> > > > > > Hi,
> > > > > > 	I was looking at the sql statements made by my torque
> > > > > application. I
> > > > > > noticed that if you retrieve an object from storage, SELECT
> > > > > .... FROM
> > > > > ...
> > > > > > WHERE ...
> > > > > >
> > > > > >  then update an attribute and call save , the all the data
is
> > > > > retrieved
> > > > > > again and then the update statement executed
> > > > > >
> > > > > > e.g. SELECT * FROM ... WHERE ID=1280
> > > > > >      UPDATE ... SET DATETIME = ?, STATUS_ID = ? WHERE ID = ?
> > > > > >
> > > > > > The torque code that is causing this in  BasePeer:
> > > > > > public static void doUpdate(
> > > > > >         Criteria selectCriteria,
> > > > > >         Criteria updateValues,
> > > > > >         Connection con)
> > > > > >         throws TorqueException
> > > > > > {
> > > > > >  ....
> > > > > > }
> > > > > >
> > > > > > Is this behaviour by torque design or the only way torque
> > > > > can update
> > > > > > records via the village library?
> > > > > > thanks
> > > > > > A
> > > > > >
> > > > > >
> > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
torque-user-unsubscribe@db.apache.org
> > > > > > For additional commands, e-mail:
> > torque-user-help@db.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > > > > For additional commands, e-mail:
torque-user-help@db.apache.org
> > > > >
> > > > >
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > > > For additional commands, e-mail: torque-user-help@db.apache.org
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > > > For additional commands, e-mail: torque-user-help@db.apache.org
> > > >
> > > >
> > >
> > >
> >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > > For additional commands, e-mail: torque-user-help@db.apache.org
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> > For additional commands, e-mail: torque-user-help@db.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org



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


Mime
View raw message