openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Heath Thomann (Commented) (JIRA)" <>
Subject [jira] [Commented] (OPENJPA-2139) OpenJPA fails to recover from a broken database on startup
Date Fri, 20 Apr 2012 17:38:40 GMT


Heath Thomann commented on OPENJPA-2139:

Hello Mark!  I worked with Albert and Rick on this issue and we came up with a slightly different
change than yours but I think it is effectively the same idea.  Please review the patch I
just uploaded, it is named 'OPENJPA-2139-1.2.x.patch'.  First, I used the OPENJPA-2139.mdr.patch
which Rick provided a while back.  This did not fix some of the issues Albert and I described
in latter posts to this JIRA (i.e. registration of a transformer).  So our approach was to
catch, and eat, the exception at the point we actually attempt to connect to the DB (as well
as log a warning message)......specifically JDBCConfigurationImpl.getDBDictionaryInstance.
 We took the approach that there is no need to allow a connection/SQLException to percolate
up the call chain.....we figured it best to catch the exception, eat it, and warn the user
of the connection issue.  In this way, and with Rick's previous patch, an attempt to connect
to the DB can be made at a later time (when hopefully the DB is back up).  I noticed that
you changed AbstractBrokerFactory.makeReadOnly.......this method eventually causes (indirectly)
JDBCConfigurationImpl.getDBDictionaryInstance to be called....when the DB is down getDBDictionaryInstance
will cause an exception to be thrown.  It appears the 'catch' block you added to AbstractBrokerFactory.makeReadOnly
will catch and re-throw this exception as well as reset some state.  With my fix, you will
no longer receive an exception in some cases (i.e. for the DB connection case where we catch/eat
the exception).  I would like you to try my patch in your testing environment to see if it
fixes your issue.  At the very least I'd like you to describe your scenario so we can understand
why you made the changes you made.  Our fix has been test in a JEE environment whereas I believe
you are in a JSE env, right?  I've tested a few scenarios in my JEE server where I've cycled
the DB at various times and our fix handles these cases as we'd expect.  Furthermore, our
fix has been tested by an internal group (who uses our JEE server) which is performing some
very rigorous DB fail over scenarios and our change fixes their issues.  So, I think our fix
is necessary, but the remaining question is whether or not your fix is needed in addition
to ours.  


> OpenJPA fails to recover from a broken database on startup
> ----------------------------------------------------------
>                 Key: OPENJPA-2139
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>            Priority: Critical
>             Fix For: 2.3.0
>         Attachments: OPENJPA-2139-1.2.x.patch, OPENJPA-2139.mdr.patch, OPENJPA-2139.patch
> The following scenario:
> 1.) turn off the database
> 2.) perform a query against the database
> 3.) turn on the database
> 4.) try to re-run the query from 2.)
> In 4.) you will get the following Exception:
> openjpa-2.2.0-r422266:1244990 nonfatal user error> org.apache.openjpa.persistence.ArgumentException:
An error occurred while parsing the query filter "SELECT k FROM DbEnumKey AS k where k.type=:typ
ORDER BY k.ordinal". Error message: The name "DbEnumKey" is not a recognized entity or identifier.
Known entity names: []
> Basically the whole app is stale afterwards!
> Solution: caching the entities might only be done if a connection can be established.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message