Re: conflict txns in serialization isolation
От
Yi LIN
Тема
Re: conflict txns in serialization isolation
Дата
Msg-id
Pine.GSO.4.44.0407231713100.27383-100000@willy
Ответ на
Re: conflict txns in serialization isolation (Tom Lane)
Список
Дерево обсуждения
conflict txns in serialization isolation Yi LIN <ylin30@cs.mcgill.ca>
Re: conflict txns in serialization isolation Tom Lane <tgl@sss.pgh.pa.us>
Re: conflict txns in serialization isolation Yi LIN <ylin30@cs.mcgill.ca>
Re: conflict txns in serialization isolation Tom Lane <tgl@sss.pgh.pa.us>
Re: conflict txns in serialization isolation Yi LIN <ylin30@cs.mcgill.ca>
Re: conflict txns in serialization isolation Kris Jurka <books@ejurka.com>
Re: conflict txns in serialization isolation Yi LIN <ylin30@cs.mcgill.ca>
> I kinda suspect that you are getting confused by JDBC autocommit > behavior and are having transactions commit when you thought they > were still open. But without a complete example it's only speculation. > > Your first gripe might also be explained by supposing that the > transactions are actually in read committed mode, and not serializable > mode at all. I realized those potential problems and in my codes: db = DriverManager.getConnection(url, username, password); db.setAutoCommit(false); db.setTransactionIsolation(java.sql.Connection.TRANSACTION_SERIALIZABLE); Even in Read-Committed isolation level, if version check is performed(as I suppose postgresql7.2 will always do), one of concurrent conflicting txns will be aborted. Read-committed is different from Snapshot in that Read-Committed txn will read data committed before read operation starts but snapshot txn will read data committed before the whole txn starts. Do I correctly understand how postgresql7.2 works? Regards, Yi
В списке pgsql-jdbc по дате отправления