> I trying to use Firebird with OpenJPA.

...

> Then i have inserted some rows in both table, 'Master' and 'Detail'.
> The problem appear when i try to update a row in 'Master' table:
>
> List<Master> masterList = null;
> EntityManager em = getEntityManagerFactory().createEntityManager();
> try {
> Query query = em.createQuery("SELECT m FROM Master m");
> masterList = query.getResultList();
> } finally {
> em.close();
> em = null;
> }
>
> System.out.println("masterList.size(): " + masterList.size());
>
> Master modified = masterList.get(0);
> modified.setDescription("master updated");

The exception you get happens because you try to access the result set
after the transaction being committed.

There are two possibilities here, you have to check which one applies
(the stack trace is not complete)

Possibility 1:

- the first part is executed in an auto-commit transaction, that means
the transaction was started, statement was executed and a result set
cursor was opened, but no records were fetched yet.

- OpenJPA does not fetch the records from the "Master"-result set, but
executes at once the "Detail"-Query. According to the rules in JDBC 3.0
specification the "Master" result set is closed.

- OpenJPA fails when it tries to access the "Master" result set...


Possibility 2:

- the first part is executed in an auto-commit transaction, that means
the transaction was started, statement was executed and a result set
cursor was opened, but no records were fetched.

- getting record from a list works, since the auto-commit transaction is
not yet committed (see rules for this case in JDBC 3.0 specification)

- you try to update the record in master table; here our auto-commit
transaction is committed and all open result sets are closed (see the
above-mentioned rules), the update is executed, but for some reason
OpenJPA tries to access the previous result set and fails.

Do not know about OpenJPA, but in Hibernate one can turn on quite
extensive logging, which would tell the exact reason.

> With OpenJPA version 1.0.2 and TopLink works fine.
>
> Any idea ?

a) You move the transaction boundaries to include also the fetching part

b) You contact OpenJPA developers and tell them to check whether there
is no bug in handling the result sets in auto-commit case

c) You specify the connection property "defaultHoldable" in the JDBC URL
(this will tell JDBC driver to cache all result sets in memory):

<property name="openjpa.ConnectionURL"
value="jdbc:firebirdsql://localhost/d:/test.fdb?defaultHoldable"/>

Note, options a) and c) are workarounds, and I am pretty sure that it is
a bug in OpenJPA, where it does not conform to the JDBC 3.0 auto-commit
rules.

Roman