Persistence Unit Initialization

[Quintin Beukes <qu...@last.za.net>]

Hey,

For each persistence unit you have an implementation backing it. This
implementation is initialized by a PersistenceProvider implementation,
which then creates the EntityManagerFactory, and so forth.

My question is, whether, in this process there are separate steps?

If I were to, for example, use Hibernate, where would the schema
generation occur?

The reason I'm asking is to find out if there is a way, whether in
each app on it's own, or collaborating, I can the schema DROPs happen
first, and then the schema CREATEs, when using multiple persistence
units.

I understand that drop/create is not part of the spec, but this is
purely out of curiosity. I modified Hibernate to do a DROP CASCADE to
drop the tables, and this leaves a semi empty database after the tests
were run. It's not a problem because it's only a test database and
made from clean everytime the tests run. This just inspired some
curiosity if such a thing would be at all possible.

Quintin Beukes

Re: Persistence Unit Initialization

[David Blevins <da...@visi.com>]

On Oct 2, 2009, at 8:04 PM, Quintin Beukes wrote:

> Hey,
>
> For each persistence unit you have an implementation backing it. This
> implementation is initialized by a PersistenceProvider implementation,
> which then creates the EntityManagerFactory, and so forth.
>
> My question is, whether, in this process there are separate steps?
>
> If I were to, for example, use Hibernate, where would the schema
> generation occur?
>
> The reason I'm asking is to find out if there is a way, whether in
> each app on it's own, or collaborating, I can the schema DROPs happen
> first, and then the schema CREATEs, when using multiple persistence
> units.
>
> I understand that drop/create is not part of the spec, but this is
> purely out of curiosity. I modified Hibernate to do a DROP CASCADE to
> drop the tables, and this leaves a semi empty database after the tests
> were run. It's not a problem because it's only a test database and
> made from clean everytime the tests run. This just inspired some
> curiosity if such a thing would be at all possible.

Pretty much all JPA Providers support some create/drop logic, but it's  
still considered vendor specific by the specs.  In practice I think  
most providers do this is in the  
PersistenceProvider.createContainerEntityManagerFactory method.  We  
call that method once only per persistence unit when the app boots.   
We call EntityManagerFactory.close() exactly once when the app  
undeploys.  Likely some providers have logic in the close() method as  
well.

Not sure if that helps, but that's how things work on our end at least.

-David