On Fri, Aug 17, 2007 at 03:18:30PM +0930, Tyson Lloyd Thwaites wrote:
It seems like something that would be fairly easy to change... I don't
know. I read someone talking about putting automatic checkpoints on
every statement that goes through the jdbc driver to get around this
issue.
The auditing is an interesting question, to which I do not have an
answer. Seems impossible to do in a transaction, by definition (ie
not product specific). Thoughts?
We do this with MSSQL. I have never given it a second thought until now.
If anything goes wrong we send an audit event,
Martijn van Oosterhout wrote:
On Fri, Aug 17, 2007 at 03:18:30PM +0930, Tyson Lloyd Thwaites wrote:
It seems like something that would be fairly easy to change... I don't
know. I read someone talking about putting automatic checkpoints on
every statement that goes through the jdbc driver
Our app uses system state. We scan filesystems and record file
information in a database.
Here is one example:
txn started by Spring in web container
- insert 250 files
- update some stats (MUST work even if insert fails)
- update agent last-contact time (also must work so we know it's not
On Fri, Aug 17, 2007 at 04:10:24PM +0930, Tyson Lloyd Thwaites wrote:
I am not familiar with the autocommit fiasco, but I can use my
imagination... :)
The changed transaction semantics caused much havoc with librarys and
drivers because client program could change the setting and driver no
It looks like it would be best if we re-worked our transactions and
controlled them manually for the portions that need it. It looks like we
have inadvertently been relying on a nasty 'quirk' ;) in MSSQL. I would
rather not go down the path of doing workarounds to make pgsql work like
mssql.
Tyson Lloyd Thwaites [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Tyson Lloyd Thwaites [EMAIL PROTECTED] writes:
Normally if we catch the exception, other dbs (Oracle, MSSQL) will let us
keep going.
How do you catch exceptions in these other dbs?
plain java try/catch. In other dbs, if I
Gregory Stark wrote:
Tyson Lloyd Thwaites [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Tyson Lloyd Thwaites [EMAIL PROTECTED] writes:
Normally if we catch the exception, other dbs (Oracle, MSSQL) will let us
keep going.
How do you catch exceptions in these other
You are right, it is a Java webapp.
I could post code, but the actual statements I am running are just plain
sql (wrapped in wrappers of wrapped wrappers...) which are run in a DAO
object in the third layer of the app. I would have to post reams of
code, which would break my non-disclosure
On Fri, 17 Aug 2007, Tyson Lloyd Thwaites wrote:
It looks like it would be best if we re-worked our transactions and
controlled them manually for the portions that need it.
I am glad you have moved so quickly through grief and into acceptance.
It is still a possible point of confusion, but I
Greg Smith wrote:
On Fri, 17 Aug 2007, Tyson Lloyd Thwaites wrote:
It looks like it would be best if we re-worked our transactions and
controlled them manually for the portions that need it.
I am glad you have moved so quickly through grief and into acceptance.
Heh heh - maybe I've had
Pgs... like a warning that you can't do this;
begin
insert 1 --works
insert 2 --fails
commit
row 1 will exist in db (yes, no kidding). This will not work in pg,
which I now see is obviously correct.
This should either a FAQ for MS-SQL or Spring, but since PG does it
canonically it
Tyson Lloyd Thwaites wrote:
I am not opposed to introducing checkpoints to our API, but it would be
nicer if I didn't have to. At the moment I have resigned myself to
turning off spring declarative txns for certain methods, and handling
them manually by doing multiple txn blocks. In the above
Webb Sprague wrote:
I am not sure how you can insert into a log even with savepoints,
unless you put the logging statement first and then follow it with the
insert.
and delete it after success?
Alternatively you could use one connection for your normal queries, and
another for auditing. Your
Sorry for top posting - but this is an annoying of this web interface to email.
:-(
Isn't what you're doing here a misuse of the idea of a transaction. I don't
claim to be an expert in this, but I thought the idea of a transaction was that
you bundle a group of statements together that
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
Hi,
I know this issue has been discussed at length before, but postgresql's
behaviour of forcing a rollback when any error occurs is making life
very difficult for me. We use Spring's transaction proxies, which are
applied to methods in web controllers. In the backend code, if a runtime
Tyson Lloyd Thwaites [EMAIL PROTECTED] writes:
Normally if we catch the exception, other dbs (Oracle, MSSQL) will let us
keep going.
How do you catch exceptions in these other dbs?
The way to do it in Postgres is with the SAVEPOINT command.
For example, if something goes wrong, I can't
Gregory Stark wrote:
Tyson Lloyd Thwaites [EMAIL PROTECTED] writes:
Normally if we catch the exception, other dbs (Oracle, MSSQL) will let us
keep going.
How do you catch exceptions in these other dbs?
plain java try/catch. In other dbs, if I am in a txn, and I run 3
statements,
it is all so easy with other dbs, but with postgresql
it is a nightmare... the only solution I can see is to remove the
declarative transactions in Spring and start using manual transactions
blocks around everything that could possibly go wrong... just because of
a quirk in postgresql
True... apologies for any offence caused. Tweaking emotion levels.
done :)
The core problem is that we are maintaining a fairly mature app, and the
behaviour in question means we effectively can't integrate with
postgresql (which is a shame - I really *really* want to... we currently
21 matches
Mail list logo
