openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: More questions on runtime schema generation
Date Fri, 27 Apr 2007 16:32:05 GMT
> > 2. It looks like the best strategy for geronimo to follow 
> is to figure 
> > out which jars in an ee app can possibly have persistent classes in 
> > them and supply a list of those jars to the 
> PersistenceUnitInfo.  IIUC 
> > scanning those jars is already implemented.
> 
> IIRC the spec limited the scope of a persistence unit to the 
> jar that contains the persistence.xml file, so we shouldn't 
> have to do deep scanning.

... but the developer can list additional jars in locations relative to
the deployed jar, and the container is responsible for providing
resolvable URLs for those jars via PUInfo.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -----Original Message-----
> From: Dain Sundstrom [mailto:dain@iq80.com] 
> Sent: Friday, April 27, 2007 9:22 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: More questions on runtime schema generation
> 
> On Apr 26, 2007, at 1:49 PM, David Jencks wrote:
> 
> > Thanks for all the comments, I've learned a lot.
> >
> > 1. I have a classloader scanning strategy written and apparently 
> > working, however it is rather slow at least in geronimo.  Is anyone 
> > interested in it, seeing as how its not an appropriate 
> approach in a 
> > app server according to Patrick's comment below?  I think it might 
> > still be useful as a "last resort" strategy.
> >
> > 2. It looks like the best strategy for geronimo to follow 
> is to figure 
> > out which jars in an ee app can possibly have persistent classes in 
> > them and supply a list of those jars to the 
> PersistenceUnitInfo.  IIUC 
> > scanning those jars is already implemented.
> 
> IIRC the spec limited the scope of a persistence unit to the 
> jar that contains the persistence.xml file, so we shouldn't 
> have to do deep scanning.
> 
> > 3. I can't get running ddl on a connection from an XADataSource in  
> > a simulated "RequiresNew" transaction to work reliably with 
> derby.   
> > The ddl appears to work fine but attempts to read data from the 
> > created sequence table hang until the tx times out and 
> derby does not 
> > report any deadlocks.  Based on Craig's comments I've added a 
> > non-jta-datasource and this seems to be working much better.  Has 
> > anyone seen problems like this?  (seems unlikely in this 
> context since 
> > i had to modify a bunch of stuff to get to this problem :-)
> 
> If the outer transaction has previously read from that table, 
> you have created a self deadlock.  Have you checked the sql 
> to make sure that there isn't a query that referenced the 
> sequence table?
> 
> -dain
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA
Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,
 copyrighted  and/or legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete it.

Mime
View raw message