I am absolutely sure that the database transaction is always terminated by =
invoking commit or rollback, and waiting for the method to come back, befor=
e the middle tier returns control to the client.
=20
A couple other potentially relevant facts are that these connections are do=
ing all this work in the SERIALIZABLE transaction isolation mode, and that =
the updates are done through ResultSet objects from prepared statements whi=
ch SELECT * on the appropriate rows.
=20
I read through the documentation of the error message, and of the way Postg=
reSQL handles the isolation levels. This is behaving as though the time th=
e PostgreSQL server assigns to the commit is sometimes later than the time =
of the subsequent transaction start, so I totally understand why you would =
ask the question you did. It is also why I checked this very carefully bef=
ore posting.
What happens if the timestamp of the commit is an exact match for the times=
tamp of the next transaction start? What is the resolution of the time sam=
pling? It may be possible that we could submit several of these, on differ=
ent connections, within the space of a millisecond. Could that be a proble=
m? (It doesn't appear to be in my simple test cases.)
=20
I don't trust the clock on the Windows client, but I wouldn't think that ha=
s anything to do with the issue.
=20
-Kevin
=20
=20
>>> Tom Lane <tgl@sss.pgh.pa.us> 08/26/05 11:10 AM >>>
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> The problem is this: a single thread is submitting database updates thro=
ugh a middle tier which has a pool of connections. There are no guarantees=
of which connection will be used for any request. Each request is commite=
d as its own database transaction before the middle tier responds to the re=
quester, which then immediately submits the next request. Nothing else it =
hitting the database. We are getting serialization errors.
Hm. Are you sure your middle tier is actually waiting for the commit
to come back before it claims the transaction is done?
regards, tom lane
