Skip site navigation (1) Skip section navigation (2)

Re: Postgres JDBC-hibernate Problem

From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
To: Freddie Burgess <fburgess(at)radiantblue(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Postgres JDBC-hibernate Problem
Date: 2012-09-19 05:31:07
Message-ID: 5059589B.5020609@ringerc.id.au (view raw or flat)
Thread:
Lists: pgsql-bugs
On 09/19/2012 03:46 AM, Freddie Burgess wrote:
>
> The Employee ingest behaves a bit differently - it handles transactions
> programmatically, for example:
>
>                    Transaction tx = session.beginTransaction();
>                    session.save(Employee);
>                    tx.commit();
>
> Could it be possible that if an exception is thrown by the session.save()
> method that the transaction might not be rolled back or closed, although no
> errors pertaining to this scenario were recorded in the PostgreSQL log.

It's possible; I don't use Spring, so I can't really say. I know that in 
EJB 3.1 container managed transactions with JTA data sources the 
guarantees are strong:

- If the exception thrown is annotated @ApplicationException then
   rollback is controlled by that annotation; otherwise:

- If it's an unchecked exception, the transaction is rolled back; and

- If it's a checked exception that's properly declared the transaction
   is NOT rolled back

I don't know what Spring's rules are. It's all a bit localized and 
specific to your code, so it's difficult to offer any useful advice at 
this point.

If there's any chance you can cook it down to a small, runnable, 
self-contained test-case that'd be very useful. In my experience when 
I've done so I have, in the process, often found a bug in my code that 
was the cause of the problem. When I don't find an issue in my code I 
usually have something clear that demonstrates a problem and helps 
isolate which project(s) the problem is in.

--
Craig Ringer


In response to

pgsql-bugs by date

Next:From: l1tDate: 2012-09-19 05:48:08
Subject: BUG #7556: "select not in sub query" plan very poor vs "not exists"
Previous:From: Peter EisentrautDate: 2012-09-19 02:06:38
Subject: Re: BUG #7548: pg_upgrade still requires pg_config

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group