From: | "Webb Sprague" <webb(dot)sprague(at)gmail(dot)com> |
---|---|
To: | |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: [RESEND] Transaction auto-abort causes grief with Spring Framework |
Date: | 2007-08-17 17:09:49 |
Message-ID: | b11ea23c0708171009h3e6983e1p2814770dc27c1936@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> Isn't the 'try' statement rather similar to a 'savepoint' command? I
> realize it would be difficult to override the behaviour of try {...}
> catch (...) {...}, but it shouldn't be too hard to wrap it somehow for
> exceptions in database code.
Yes, but I believe the OP was getting two levels of his application
mixed up: he was doing something that caused a rollback in the
*database*, then hoping to recover in a catch block in the
*application* without terminating the aborted transaction in the
database. Or so I gather.
You are right in another post about the purpose and design of
transactions, and don't use the discussion here as a model, though
drivers seem to often do weird stuff with transactions behind your
back. Psycopg (python) does an implicit begin, so you must commit,
which then starts another begin automatically. I think you can set a
handle to do autocommit, but I never do. This seems best because it
forces you to handle transactions explicitly, but I can imagine other
(bad) approaches, and Spring may use them (though I think the
difficulty is that MS-SQL is sloppy, not Spring, and that the OP is
still getting used to TX's and MS-SQL covered up some things that
shouldn't have been covered).
W
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2007-08-17 17:17:58 | Re: Enterprise Wide Deployment |
Previous Message | Belinda M. Giardine | 2007-08-17 17:00:01 | Re: FInding "corrupt" values in UTF-8 tables (regexp question, I think) |