Re: [Hibernate-devel] Hibernate + JNDI (+serialization)

[Gavin_King/Cirrus%<CI...@ci...>]

>For multiple datasources, use multiple instances of SessionFactory. Each
>>instance of SessionFactory may be configured using a different set of
>>properties by using
>>
>>  Datastore datastore = Hibernate.createDatastore()........;
>>  Properties props = .... ;
>>  SessionFactory sf = datastore.buildSessionFactory(props);
>>

>sorry, i was not aware of this (as i said, i'm new to hibernate :). so,
>if you specify a hibernate.session_factory_name at this level, it takes
>precedence over whatever VM level properties you might have?

Exactly :)

The properties contain all the database connection parameters, etc, so
this is the generic way of accessing multiple datastores.


==========================

What I just finished doing (right now) was implementing Serialization for
Sessions. This turned out to be mush easier than I expected (I had been
putting it off for ages because I had been expecting pain) but it still
isn't heavily tested.

What this new feature means, though, is that you can maintain an open,
disconnected Session in a session bean or servlet with HttpSession
failover. The only requirement is that your business objects also be
serializable.

If you have more than one SessionFactory in the application and you want to
be able to migrate between servers, you are going to need to provide names
for the SessionFactories, unfortunately. (The Session needs to know which
is "its" Factory - even if it moves from one machine to another.)

What I've got at the moment is this:

1. If no name is specified in hibernate.session_factory_name, the
SessionFactory gets a name like "hibernate/session_factory/default/1". This
name is just used internally by the serialization mechanism. The
SessionFactory is NOT bound into JNDI.

2. If a name is specified, hibernate attempts to bind the SessionFactory to
that name (using hibernate.jndi.class + hibernate.jndi.url OR VM defaults
if these are not specified).

3. If we fail to bind, report that in the log, and carry on, using the name
internally for the serialization mechanism.

Does that sound reasonable?