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 Mon, 26 Mar 2012 22:42:28 GMT


Heath Thomann commented on OPENJPA-2139:

Hey Rick!  Let me try to answer the question you posed previously in response to Albert's
comments.  If you look at PersistenceProviderImpl.createContainerEntityManagerFactory you
can see we have this code:

            try {
                pui.addTransformer(new ClassTransformerImpl(cp, ctOpts,
                    pui.getNewTempClassLoader(), newConfigurationImpl()));
            } catch (Exception e) {
                // fail gracefully
                transformerException = e;

Within the 'addTransformer' call, we are doing a bunch of stuff which includes instantiating
a 'ClassTransformerImpl' (CTI).  You'll have to take a leap of faith a bit and trust me when
I say that as part of instantiating the CTI, a call is eventually made to 'DBDictionaryFactory.newDBDictionary'.
 Within 'newDBDictionary', a connection to the DB is made.  If an exception is thrown when
making the connection (e.g. DB is down), the exception flows all the way back to the try/catch
in the above code block.  That means we never add a later at runtime we'd
see the ArgumentException given the lack of transformer/enhancement registration.  Furthermore,
as you can see in the catch block we attempt to "fail gracefully" which means to me in what
I see in my env that there isn't much indication of the fact that we didn't register a transformer.
 So the patch you added previously doesn't work in this case because it does nothing to handle
the case where we go down the 'createContainerEntityManagerFactory' path.  I'm working on
a patch which will "eat" any connection errors at the point 'DBDictionaryFactory.newDBDictionary'
is called (i.e. JDBCConfiguratoinImple.getDBDictionaryInstance)....the code will be gated
by a system property of course.

IMHO, it seems OpenJPA needs to take a long hard look at these DB up/down scenarios.  In what
little testing has been down via this JIRA, we've unearthed a few areas needing to be changed.
 What other issues could be lurking as further testing is done?  That is, could we be opening
a can of worms by fixing this limited scenario given OpenJPA doens't appear to do much/any
testing in this area (one could think of a million DB up/down scenarios and timing windows)?
 Anyway, I'm always the pessimist.......  :-)


Heath Thomann
> 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.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