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

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(at)xythos(dot)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(at)xythos(dot)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(at)postgresql(dot)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(at)postgresql(dot)org
>