openejb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Persistence Unit Initialization
Date Fri, 09 Oct 2009 06:07:10 GMT

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


Mime
View raw message