Thread: Synchronization issues with pg73jdbc3.jar and pg73jdbc2ee.jar
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
Attachment
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
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 > > > > >
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 >> >> >> >> >> >