openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <ppod...@apache.org>
Subject Re: JPA2 - When should createEMF() return an Exception vs. NULL?
Date Fri, 24 Jul 2009 11:50:14 GMT

Depends what the bootstrap assume about the providers :
   well behaved (they will log their failure before throwing an exception)
-- that is the optimistic view 
or not so well behaved (i.e. they simply throw exception) -- that is the
pessimistic view.

For a bootstrap class, a pessimistic world view help, imo.

If the bootstrap swallows the exception for provider A without logging,
finds provider B and returns it,
the deployer will have a hard time to fathom why provider A is not loading. 
The reason of not logging because "we currently do not require a log
provider" may be good for explanation, but it does not really help anybody. 

Consider the case that you originally mentioned. Someone has configured
"openjpa.Specifcation=3.0" in a persistence.xml file and deployed. The
environment has OpenJPA as the only provider. Now the bootstrap calls
OpenJPA, OpenJPA throws exception, the bootstrap swallows the exception, and
returns null. What will the deployer do to diagnose the error? In fact
instead of helping, the bootstrap effectively made the situation worse by
hiding the informative exception thrown by the provider. Why? because such
and such spec said so or did not say we have to log.

> as the way I read the spec is the *first* provider that creates 
> an EMF should be the one that gets returned.

The operative word is *first*. Who is the *first* provider?
Whichever way you may define *first* case, cutting the search at the first
available provider is unfair policy.
The spec does say though that no order is implied in the list of providers. 

> a javax.persistence.provider property on the createEMF call, 
> which should effective make that the only provider that should try to 
> create a EMF

The case that a bootstrap must defend against is where the property is not
specified.
Even if the property is specified, but a provider A who happens to be
*first* returns a
non-null EMF, while the javax.persistence.provider actually points to the
next provider B,
what will be the fair behavior : to return A or B? 

> Also, I don't see it as 
> the javax.persistence.Persistence impls job to cache and free these EMFs 
> (nothing in the spec suggests this behavior.)

And i do not see why one needs to cache *local* variables or free them to
get a robust behavior.


DWoods wrote:
> 
> 
> 
> Pinaki Poddar wrote:
>> The bootstrap should ask all (say N) available providers to createEMF().
>> If any of them throws exception or return null, the bootstrap should
>> continue asking rest of the providers.
>> After all N provides have been queried by the bootstrap, let us say M
>> providers have returned a valid EMF.
>> 
>> 
>> 1. Log exceptions or null, as the case may be, for each of the (N-M)
>> failed
>> providers to give a deployer a chance to know what went wrong.
> 
> We currently do not require a log provider for the Geronimo Specs, as 
> you have no idea what logging will be in place (Log4j, SLF4J, JDK, OSGi, 
> .....)  Since the spec says to return null and doesn't define an 
> exception to throw, it should be up to the providers to log why they 
> couldn't create an EMF.
> 
>> 
>> 2. if (M == 1)
>>    return the only good one. 
>> else if (M > 1)
>>    tricky. Non-partisan approach will be to throw exception explaining
>> that
>> providers are behaving badly.
> 
> Disagree, as the way I read the spec is the first provider that creates 
> an EMF should be the one that gets returned.  Also, I don't see it as 
> the javax.persistence.Persistence impls job to cache and free these EMFs 
> (nothing in the spec suggests this behavior.)  I would rather we ask the 
> expert group for clarification, than create a nightmare for us to test.
> 
>>    Partisan behavior will be to return OpenJPA provider, if exists. If
>> not
>> the first one (unfair, because *first* is ambiguous/non-deterministic).
>> else // M = 0
>>    return null or throw exception
>> 
>> The key points are
>> a) robust: not to let one *failed* provider spoil the chance of other
>> good
>> ones
> 
> agree
> 
>> b) fair: not to prefer one provider over another (slight bias towards
>> OpenJPA is OK:). This will address the  case of more than one provider
>> returning non-null EMF. Also do not return immediately at the first
>> non-null
>> EMF. Because the ordering on provider is inherently non-deterministic due
>> to
>> the nature of the discovery process.
> 
> don't see this as a problem, as 1) the spec defines support for 
> providing a javax.persistence.provider property on the createEMF call, 
> which should effective make that the only provider that should try to 
> create a EMF, 2) we could look at the discovered list of persistence 
> providers and try loading ours first.
> 
>> c) helpful: provide as much contextual info as possible for diagnosis
>> (the
>> deployer/developer will be pleased)
> 
> again, see this as the job of each provider, to log why they could not 
> return a valid EMF (since they have to handle logging in JSE, JEE and 
> OSGi today)
> 
>>    
>> 
>> So if OpenJPA is throwing exception on unsupported openjpa.Specification
>> property value, let it continue to do so. Others may return null under
>> certain circumstances, or throw exception in another.
>> 
>> Absorb the provider implementation variations in the bootstrap. 
>> 
>> 
>> -----
>> Pinaki 
> 
> 


-----
Pinaki 
-- 
View this message in context: http://n2.nabble.com/JPA2---When-should-createEMF%28%29-return-an-Exception-vs.-NULL--tp3312130p3315250.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.

Mime
View raw message