Re: Fwd: Re: Synchronization issues with pg73jdbc3.jar and pg73jdbc2ee.jar

No, the connections all get passed to the reader method, so they all use
the exclusive lock in the transaction, since it has been set to
Connection.TRANSACTION_SERIALIZABLE.

I promise, this is the last mail from me on the matter, but I AM pretty
sure, that this should not happen. What's the use of preventing dirty-
reads, if I can do one (hence the program attached in my previous post)?

I AM sure, that what the driver does should not happen if
TRANSACTION_SERIALIZABLE is fully and correctly implemented.

Regards
Andras

PS: If everyone else is sure that all JDBC drivers behave this way, I might
just back up, although I'm still curious then, what this feature is for.

On Mon, 26 May 2003 13:21:41 -0700, Barry Lind <blind@xythos.com> wrote :

> Andres,
>
> When your code starts up each transaction reads the current max(id).
> All transactions see the same value and therefore all try to insert the
> same value.  This has nothing to do with dirty reads.
>
> --Barry
>
>
> Gerlits AndrXs wrote:
> > Taken from: http://www.jguru.com/faq/view.jsp?EID=721
> >
> > Dirty read:
> >
> > "Quite often in database processing, we come across the situation
wherein
> > one transaction can change a value, and a second transaction can read
this
> > value before the original change has been committed or rolled back.
This is
> > known as a dirty read scenario because there is always the possibility
that
> > the first transaction may rollback the change, resulting in the second
> > transaction having read an invalid value."
> >
> > This is exactly the thing that should not happen with my code, but it
does.
> >
> > The idea was to prove that the synchronization is unstable when it
comes to
> > serializable transactions. I might just push myself into a deeper hole,
but
> > as far as I know, the whole idea of serializable transaction handling
is to
> > be able to acquire an exclusive access to the needed fields. According
to
> > the JDBC 2.1 javadoc:
> >
(http://java.sun.com/products/jdk/1.2/docs/api/java/sql/Connection.html#TRAN
> > SACTION_SERIALIZABLE)
> >
> > "Dirty reads, non-repeatable reads and phantom reads are prevented."
> >
> > This should mean that I shouldn't be seeing the stack-trace you saw too.
> >
> > Regards.
> > Andras
> > (Which is my first name, it's all mixed up in Hungarian :))
> >
> > On Mon, 26 May 2003 11:51:03 -0700, Barry Lind <blind@xythos.com>
wrote :
> >
> >
> >>Gerlits,
> >>
> >>I still don't understand your problem.  From what I can see the
database
> >>is doing the correct thing.  You issue a bunch of selects that will all
> >>return the same value, and then you try to insert that value into a
> >>table with a unique index and you end up with duplicate key in index
> >
> > errors.
> >
> >>thanks,
> >>--Barry
> >>
> >>Gerlits AndrXs wrote:
> >>
> >>>Those stacktraces are exactly my concern. I don't expect my code to
> >
> > behave
> >
> >>>like that :).
> >>>
> >>>On Mon, 26 May 2003 11:30:50 -0700, Barry Lind <blind@xythos.com>
> >
> > wrote :
> >
> >>>
> >>>>Gerlite,
> >>>>
> >>>>I ran the test program you submitted and it seems to run OK (other
than
> >>>>some duplicate key in index errors).  What is the problem you are
> >>>>seeing?  Specifically what are you expecing to happen, and how does
> >
> > what
> >
> >>>>you are seeing differ from your expectatations.
> >>>>
> >>>>thanks,
> >>>>--Barry
> >>>>
> >>>>Gerlits AndrXs wrote:
> >>>>
> >>>>
> >>>>>Attached you'll find a simple multi-threaded example of a couple of
> >>>>>SERIALIZABLE transactions. I hope, I'm not making a complete ass of
> >>>
> >>>myself,
> >>>
> >>>
> >>>>>but it seems that the JDBC driver is unprepared to handle
simultaneous
> >>>>>SERIALIZABLE transactions.
> >>>>>
> >>>>>The table structure to test with is really simple:
> >>>>>
> >>>>>CREATE TABLE test (
> >>>>>   id integer UNIQUE NOT NULL
> >>>>>);
> >>>>>
> >>>>>The program tries to access the database for the highest id
available,
> >>>
> >>>then
> >>>
> >>>
> >>>>>use it in a preparedstatement.
> >>>>>
> >>>>>(The reason we do that is to prepare for the worst DB server
> >
> > available,
> >
> >>>we
> >>>
> >>>
> >>>>>know that there are other ways to do this in postgres.)
> >>>>>
> >>>>>It first opens the connections, stores them, than hands them to the
> >>>
> >>>threads.
> >>>
> >>>
> >>>>>No connection is issued twice simultaneously.
> >>>>>
> >>>>>Please edit the variables at the top, but check not to have more
> >>>>>InserterThreads than dbConnections.
> >>>>>
> >>>>>Thanks
> >>>>>Andras Gerlits
> >>>>>
> >>>>>
> >>>>>---------------------------------------------------------------------
--
> >
> > -
> >
> >>>>>
> >>>>>---------------------------(end of broadcast)------------------------
--
> >
> > -
> >
> >>>>>TIP 3: if posting/reading through Usenet, please send an appropriate
> >>>>>subscribe-nomail command to majordomo@postgresql.org so that your
> >>>>>message can get through to the mailing list cleanly
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> >
>
>
>
>
>