Re: [GENERAL] How to make a read-write atomic?

hi daniel,

Since ex_locks would make some new limitations, for better design,I suggest
that you minimize the time interval between reading the costomerid# and
writing back its ++ .This would make the undesiered event less probable to
accure. I think you are going to use the ID# in an application form (or some
sort of interactiv UIF). So if you really don't need to reserve the ID# (eg.
showing ID# above the form )at the begining, let it be assigned at the time
of submitting.In other hand, any customer can get his new ID# after filling
and sending his data not before that.
Ofcourse there is more than one way skinning a pig!

good luck ,
omid.

>From: Vadim Mikheev <vadim(at)krs(dot)ru>
>To: Daniel Stolk <stolkd(at)email(dot)com>
>CC: pgsql-general(at)postgreSQL(dot)org
>Subject: Re: [GENERAL] How to make a read-write atomic?
>Date: Thu, 02 Sep 1999 09:39:22 +0800
>
>Daniel Stolk wrote:
> >
> > Hi,
> >
> > I used to use the BEGIN-COMMIT pair in order to ensure that two
> > processes didn't read the same data and write at the same time, so
> > messing things up. But I've recently upgraded to the latest version of
> > postgresql and now it doesn't work anymore. Does anybody know what's
> > going on?
> >
> > To explain my situation in more detail:
> > I want a process to read the database for the entry that has the highest
> > customerid number. I then want the process to write the next entry into
> > the database with a customerid that is one larger. But if two processes
> > read at the same time, then they will both write an entry that has the
> > same customerid number. How do I keep this from occurring since the
> > BEGIN command doesn't seem to work for me anymore?
>
>Use LOCK TABLE IN SHARE ROW EXCLUSIVE MODE before reading max
>customerid. Please read doc and "Migration to v6.5" in HISTORY.
>
>Vadim
>
>************
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com