geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <>
Subject [jira] Commented: (GERONIMO-5451) JPA table generation fails on JTA datasources
Date Mon, 19 Jul 2010 17:05:50 GMT


David Jencks commented on GERONIMO-5451:

Even if using only the jta-datasource works with other databases, it's almost certain to be
slower than using both a jta and non-jta datasource, at the cost of a few more lightly-used
database connections.  Openjpa needs to use a non-transactional db connection for both creating
tables and for fetching new key values.  If you don't supply extra non-transactional connections
for it to use it will try to use the xa connection it already has by suspending the jta tx,
fetching the new key value(s), and resuming the tx.  This involves at least 2 extra calls
to the db, which are apt to be particularly slow because most db vendors don't really expect
you to ever call suspend/resume.  My observations (from several years ago) on derby is that
after the suspend or resume it has forgotten what db you are talking to.

In any case, if you want to use only the one jta datasource, and are having problems, you
should take it up with openjpa or the database vendor.

> JPA table generation fails on JTA datasources
> ---------------------------------------------
>                 Key: GERONIMO-5451
>                 URL:
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>    Affects Versions: 2.1.5, 2.1.6
>         Environment: Vista using current Java 1.6 and embedded Derby
>            Reporter: Knut-HÃ¥vard Aksnes
> I am calling a number of JPA beans from a local Web service implemented via JAX-WS annotations
and  Stateless Session Bean.
> Table creation fails due to some operations during table creation being run outside a
transaction context.
> Workaround:
> First set up the Database Pool and persistence.xml to use a Local(Non JTA) setup. Table
creation will succeed, but the rest of my code will fail.
> Then uninstalling my EAR and removing the DBPool, but keeping the Local Derby database.
> Then creating new JTA enabled DB pool for the same underlaying database, fixing the persistence.xml,
rebuild the EAR, and reinstall.
> As this has to be done everytime OpenJPA needs to update tables this is a major hassle
during development.
> If the workaround hadn't required so much work this would have been a minor bug.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message