Ummm, didn't want to butt in, but why r u multi-threading a read, then
write to Oracle?
Without using roll locking, wouldn't it be the right thing to do using
synchronized thread e.g. like this
import java.io.*;
public class ModifyAccountBalance
{
DespositThread Deposit1, Deposit2;
Deposit1 = new DepositThread(account, 1234);
Deposit2 = new DepositThread(account, 4321);
// strut yourstuff here
}
synchronized void Deposit (int depositAmt, String accountName)
{
// codes for updating the account balance
}
class DepositThread extends Thread
{
// more codes
DepositThread
(...)
{ // you might like to set the amounts etc here
}
public void run()
{
account.Deposit(depositAmt, accountName);
}
}
John Zukowski's books explain that in detail.
Using synchronization, the first deposit will write and update Oracle
before the second deposit kicks in.
What I would like to know is if I have multile JVMs, would this model
hold true ?????? It should since TC starts up one instance and
multi-thread it, but we have programmatically forced it to be singled
threaded.
Like to hear back n this one.
Johan Kok wrote:
>
> Wish I could, it's been eight years since I was did any DBA/DB development
> work. Either go to the manual, or contact a oracle list.
>
> > -----Original Message-----
> > From: Antony Paul [mailto:[EMAIL PROTECTED]
> > Sent: 03 November 2003 09:10
> > To: Tomcat Users List; [EMAIL PROTECTED]
> > Subject: Re: Design advice needed.
> >
> >
> > Can u pls mention what is that Oracle feature ?. Reading the
> > data again is
> > time consuming.
> > ----- Original Message -----
> > From: "Johan Kok" <[EMAIL PROTECTED]>
> > To: "'Tomcat Users List'" <[EMAIL PROTECTED]>
> > Sent: Monday, November 03, 2003 12:17 PM
> > Subject: RE: Design advice needed.
> >
> >
> > > Anthony,
> > >
> > > Did you consider reading the record without locks, and when
> > an updated are
> > > made, to take a write-lock, check that the original record
> > are still the
> > > same and then apply, otherwise fail.
> > >
> > > Your intentions might not work unless all writes are passed
> > through the
> > > container, as Oracle will not have any control, until a
> > write occurs, i.e.
> > > you will have to open with read only, and only take out a
> > lock when you
> > are
> > > going to write, as described above. for safety sake your
> > container will
> > have
> > > to re-read the data in any case, before commiting,
> > otherwise it may update
> > > changed data, e.g. updates that are made through other
> > processes or even
> > > triggers.
> > >
> > > If my memory serves me right, that is something you can do
> > easily with
> > > Oracle (i.e. there's a standard feature implemented), even
> > with Oracle
> > 6/7.
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Antony Paul [mailto:[EMAIL PROTECTED]
> > > > Sent: 03 November 2003 08:36
> > > > To: Tomcat Users List
> > > > Subject: Design advice needed.
> > > >
> > > >
> > > > Hi all,
> > > > I need a replacement for row level locking in database.
> > > > The requirement
> > > > is if two users are updating the same row of a table only
> > the user who
> > > > updates first will be made to database second user must
> > get a failed
> > > > message. This can be done using row level locking. But it
> > > > allows only one
> > > > user to open page for editing at same time. If another user
> > > > has locked the
> > > > row then second user cannot lock the same row or update it.
> > > > So I want to
> > > > implement locking in Container. Is there any design patterns
> > > > available for
> > > > this. Or have anyone implemented this. I am using Tomcat
> > > > 4.1,Servlets JSP
> > > > and Oracle 8i. The application is using MVC pattern but do
> > > > not use Struts.
> > > >
> > > > Antony Paul
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
