[hibernate-dev] EMF / EM properties

[Emmanuel Bernard]

On 25 janv. 2010, at 02:27, Steve Ebersole wrote:

> There have been a few discussions on IRC about handling getProperties()
> & setProperty(..) handling in regards to the EMF and EM.  I wanted to
> expand this discussion here so that:
> 1) we get a broader audence/participation;
> 2) we get a record of the discussion :)
> 
> We have to consider 2 axes if you will, the first being the availability
> of a particular setting for EM versus EMF and the second being JPA
> defined settings versus "vendor specific" settings.  For Hibernate, the
> vast majority of "vendor specific" settings are available already from
> org.hibernate.cfg.Environment; those happen to be EMF/SF specific for
> the most part.
> 
> We've added others in the new org.hibernate.ejb.AvailableSettings.  This
> is a mix of JPA defined settings plus some additional
> Hibernate-EM-specific settings.  I like the idea of
> org.hibernate.ejb.AvailableSettings specifically because it consolidates
> all the setting names in a single place.

The "historical" setting repository for HEM is HibernatePersistence. Are we deprecating it?

> 
> On Friday on IRC Hardy and I began discussing the idea of "Setting"s as
> an internal contract that describes how a setting is applied.  Take the
> case of EM, there we'd have a series of named Settings that are specific
> to EM.  We described a pretty simplistic interface, something like:
> interface EntityManageSetting {
>    public void apply(SessionImplementor session, Object value);
>    public Object determineValue(SessionImplementor session);
> }
> 
> Then the pseudo-code for EM.setProperty becomes:
> public void setProperty(String name, Object value) {
>    final EntityManageSetting setting = getSetting( name );
>    if ( setting != null ) {
>        // recognized setting
>        setting.apply( getSessionImplementor(), value );
>    }
>    //else {
>    //    setting was not recognized, ignore per spec
>    //}
> }
> 
> The EntityManager impl would then have a set of settings:
> private static Map<String name,EntityManageSetting> settingHandlers
>        = new ConcurrentHashMap<String name,EntityManageSetting>();
> static {
>    settingHandlers.put(
>            SHARED_CACHE_RETRIEVE_MODE,
>            new EntityManagerSetting() {
>                ...
>            }
>    );
>    ...
> }
> 
> And something similar for EMF.

This approach probably works fine for EM but EMF's settings have to be read at configuration time as they influence each other in a non trivial way. They are basically part of the state machine used to retrieve the list of mappings (ann or xml), some of the key configurations (JTA vs non JTA which influences how the datasource is provided etc). We would need to read these setting at least two times:
 - once at Configuration time
 - once at SF creation time

> 
> One thing I did not see an answer for is how changes to a EMF setting is
> supposed to affect an existing EM.  Take cache-store-mode; consider:
> EntityManagerFactory emf = ...;
> emf.setProperty( 
>        "javax.persistence.cache.storeMode", 
>        CacheStoreMode.BYPASS 
> );
> EntityManager em = emf.createEntityManager(); 
> // Now, by spec em should behave as CacheStoreMode.BYPASS because
> //  the store mode is not overridden on it
> .setProperty( 
>        "javax.persistence.cache.storeMode", 
>        CacheStoreMode.USE 
> );
> // Now what cache-store-mode is in effect for the em?
> //  Intuitively I think CacheStoreMode.BYPASS makes the most sense, 
> //    but the spec does not say one way or the other that I saw.
> 

EMF#setProperty is not a contract, at least in JPA 2: we have removed it in the last draft before running final.
If we want to implement that as an extension, I am in favor of applying the new settings to all the new EM being created from now on and not affect existing ones.