[
https://issues.apache.org/jira/browse/OPENJPA-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238926#comment-13238926
]
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
transformer......so 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....... :-)
Thanks,
Heath Thomann
> OpenJPA fails to recover from a broken database on startup
> ----------------------------------------------------------
>
> Key: OPENJPA-2139
> URL: https://issues.apache.org/jira/browse/OPENJPA-2139
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
