[jira] Created: (OPENJPA-142) Entity name is ignored when specified in the orm.xml file
Entity name is ignored when specified in the orm.xml file
-
Key: OPENJPA-142
URL: https://issues.apache.org/jira/browse/OPENJPA-142
Project: OpenJPA
Issue Type: Bug
Components: jpa
Reporter: Marc Prud'hommeaux
The XMLPersistenceMetaDataParser ignores the "name" attriburte of an "entity"
element, and instead always uses the default alias. For example, with the
following declaration in the orm.xml file:
the entity will be aliased to "Bar", rather than to "Foo".
Original report by Dain Sundstrom on the open-jpa-dev mailing list:
I'm using 0.9.6 and it appears the OpenJPA is ignoring the entity name when
processing queries. In stead it seems to always choose the class name for the
schema name of the bean. For example, I have the following bean declared in my
entity mappings:
BasicCmp2Bean
The following query does not work:
SELECT o FROM BasicCmp2Bean o WHERE o.lastName = ?1
But this one does:
SELECT o FROM BasicCmp2Bean_BasicCmp2Bean o WHERE o.lastName = ?1
When the query fails, I get this message (reformatted a bit with ** added to
important entries):
ERROR - The bean instances business method encountered a system exception:
Could not locate metadata for the class using alias "BasicCmp2Bean". Registered
alias mappings: "{
AllowedOperationsCmp2Bean_AOBasicCmp2Bean=
[class
org.apache.openejb.test.entity.cmp.AllowedOperationsCmp2Bean_AOBasicCmp2Bean],
AllowedOperationsCmpBean=
[class org.apache.openejb.test.entity.cmp.AllowedOperationsCmpBean],
ContextLookupCmpBean=
[class org.apache.openejb.test.entity.cmp.ContextLookupCmpBean],
Employee=
[class org.apache.openejb.test.entity.cmp2.Employee],
ManyOwningSideBean_ManyOwningSideBean=
[class
org.apache.openejb.test.entity.cmr.cmrmapping.ManyOwningSideBean_ManyOwningSideBean],
**BasicCmp2Bean_BasicCmp2Bean=
[class org.apache.openejb.test.entity.cmp.BasicCmp2Bean_BasicCmp2Bean],
EncCmpBean=
[class org.apache.openejb.test.entity.cmp.EncCmpBean],
BBean_OneToOneB=
[class org.apache.openejb.test.entity.cmr.onetoone.BBean_OneToOneB],
OneOwningSideBean_OneOwningSideBean=
[class
org.apache.openejb.test.entity.cmr.cmrmapping.OneOwningSideBean_OneOwningSideBean],
ABean_OneToOneA=
[class org.apache.openejb.test.entity.cmr.onetoone.ABean_OneToOneA],
**BasicCmp2Bean=null,
RmiIiopCmpBean=
[class org.apache.openejb.test.entity.cmp.RmiIiopCmpBean],
ABean_OneToManyA=
[class org.apache.openejb.test.entity.cmr.onetomany.ABean_OneToManyA],
OneInverseSideBean_OneInverseSideBean=
[class
org.apache.openejb.test.entity.cmr.cmrmapping.OneInverseSideBean_OneInverseSideBean],
BBean_OneToManyB=
[class org.apache.openejb.test.entity.cmr.onetomany.BBean_OneToManyB],
RmiIiopCmp2Bean_Cmp2_RMI_IIOP_Bean=
[class org.apache.openejb.test.entity.cmp.RmiIiopCmp2Bean_Cmp2_RMI_IIOP_Bean],
EncCmp2Bean_EncCmp2Bean=
[class org.apache.openejb.test.entity.cmp.EncCmp2Bean_EncCmp2Bean],
BasicCmpBean=
[class org.apache.openejb.test.entity.cmp.BasicCmpBean]}"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Do mapped superclasses work at all in OpenJPA?
Dain- I just did a quick test with a mapped-superclass using an orm.xml descriptor with all attributes defined in the superclass, and it worked fine for me. Are you using dynamic runtime enhancement, or build-time enhancement? Can you enable TRACE-level logging (by setting the "openjpa.Log" property to "DefaultLevel=TRACE"), and send us the output from your test run? Also, seeing your persistence.xml might help shed light on the issue... On Feb 12, 2007, at 10:42 PM, Dain Sundstrom wrote: Are you sure that is the right issue? It seems to be about a different problem. -dain On Feb 12, 2007, at 7:14 PM, Craig L Russell wrote: Hi Dain, This might be related to a bug in xml overrides http:// issues.apache.org/jira/browse/OPENJPA-97. Just fer grins, do you have a way to annotate the mapped superclass? Craig On Feb 12, 2007, at 7:01 PM, Dain Sundstrom wrote: When I try to use a simple mapped super class with a trivial sub class (no fields or methods), I get the following exception: ERROR - The bean instances business method encountered a system exception:org.apache.openejb.test.entity.cmp.BasicCmpBean.pcGetManag edFieldCount()I java.lang.NoSuchMethodError: org.apache.openejb.test.entity.cmp.BasicCmpBean.pcGetManagedFieldCou nt()I at openejb.org.apache.openejb.test.entity.cmp.BasicCmpBean. (Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.apache.openjpa.meta.MetaDataRepository.classForName (MetaDataRepository.java:1224) at org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypes (MetaDataRepository.java:1212) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings (JDBCBrokerFactory.java:145) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl (JDBCBrokerFactory.java:127) at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker (AbstractBrokerFactory.java:164) at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker (DelegatingBrokerFactory.java:139) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntity Manager(EntityManagerFactoryImpl.java:187) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntity Manager(EntityManagerFactoryImpl.java:52) at org.apache.openejb.persistence.JtaEntityManagerRegistry.getEntityMan ager(JtaEntityManagerRegistry.java:105) Which seems to indicate to me that OpenJPA isn't enhancing the mapped super class. Does OpenJPA support mapped super classes? Here is are my entity mappings: http://java.sun.com/xml/ns/persistence/ orm" version="1.0"> class="org.apache.openejb.test.entity.cmp.BasicCmpBean"> class="openejb.org.apache.openejb.test.entity.cmp.BasicCmpBean"> BasicCmpBean Thanks for any help, -dain Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Re: Do mapped superclasses work at all in OpenJPA?
Are you sure that is the right issue? It seems to be about a different problem. -dain On Feb 12, 2007, at 7:14 PM, Craig L Russell wrote: Hi Dain, This might be related to a bug in xml overrides http:// issues.apache.org/jira/browse/OPENJPA-97. Just fer grins, do you have a way to annotate the mapped superclass? Craig On Feb 12, 2007, at 7:01 PM, Dain Sundstrom wrote: When I try to use a simple mapped super class with a trivial sub class (no fields or methods), I get the following exception: ERROR - The bean instances business method encountered a system exception:org.apache.openejb.test.entity.cmp.BasicCmpBean.pcGetManage dFieldCount()I java.lang.NoSuchMethodError: org.apache.openejb.test.entity.cmp.BasicCmpBean.pcGetManagedFieldCoun t()I at openejb.org.apache.openejb.test.entity.cmp.BasicCmpBean. (Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.apache.openjpa.meta.MetaDataRepository.classForName (MetaDataRepository.java:1224) at org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypes (MetaDataRepository.java:1212) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings( JDBCBrokerFactory.java:145) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl (JDBCBrokerFactory.java:127) at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker (AbstractBrokerFactory.java:164) at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker (DelegatingBrokerFactory.java:139) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityM anager(EntityManagerFactoryImpl.java:187) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityM anager(EntityManagerFactoryImpl.java:52) at org.apache.openejb.persistence.JtaEntityManagerRegistry.getEntityMana ger(JtaEntityManagerRegistry.java:105) Which seems to indicate to me that OpenJPA isn't enhancing the mapped super class. Does OpenJPA support mapped super classes? Here is are my entity mappings: http://java.sun.com/xml/ns/persistence/ orm" version="1.0"> class="org.apache.openejb.test.entity.cmp.BasicCmpBean"> class="openejb.org.apache.openejb.test.entity.cmp.BasicCmpBean"> BasicCmpBean Thanks for any help, -dain Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
RE: Using @GeneratedValue for IDs on already existing tables
How do you currently generate your values? If you use some sort of database-side logic (sequence, auto-assigned columns, hi-lo table), it should be trivial for Kodo to interoperate. If you're using some sort of fancy in-process algorithm, it may be more difficult, but is certainly doable. -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: Hans J. Prueller [mailto:[EMAIL PROTECTED] > Sent: Saturday, February 10, 2007 9:24 AM > To: open-jpa-dev@incubator.apache.org > Subject: Using @GeneratedValue for IDs on already existing tables > > As some of you may remember, I am using OpenJPA within an > "old" Java2EE > 1.4/EJB2.1 container to perform > > a step-by-step or bean-by-bean migration from our EJB2.1 CMP > entity beans to > new EJB3 Beans with JPA. > > > > For the IDs of the Entity Beans we have been using a > Container-Generated-Value and I plan to continue doing > > so by using the JPA's @GeneratedValue stuff. > > > > Are there any special issues to consider when using the new > openJPA based > entities with generated values > > on already existing data? In special I mean conflicts of > between openJPA > generated IDs with existing IDs in > > the underlying table? > > > > Hans > >
RE: NoSuchFieldException
> Does anyone know if I can declare a mapped-superclass with
> all fields declared as transient and then use attribute-override
> in the subclass for fields I want to map?
I think that your use case should work, modulo the issue that you're
running into in the other thread.
-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:[EMAIL PROTECTED]
> Sent: Monday, February 12, 2007 5:55 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: NoSuchFieldException
>
> I think I need to declare a mapped-superclass, and then use
> attribute-
> overrides in the subclass.
>
> Does anyone know if I can declare a mapped-superclass with
> all fields
> declared as transient and then use attribute-override in the
> subclass
> for fields I want to map? I would be easier for me to code it that
> way (and yes I am quite lazy).
>
> -dain
>
> On Feb 12, 2007, at 4:00 PM, Dain Sundstrom wrote:
>
> > I have this scenario in my CMP2JPA tool where I have to generate
> > subclasses of CMP1 beans. When the user has an "unknown" primary
> > key or more commonly, when they use the same ejb class for
> multiple
> > deployments, I have to generate a sub class to either add an extra
> > field, or to differentiate two usages of the same class. So say I
> > have the class "foo.TestBean", like this:
> >
> > package foo;
> > public class TestBeanEJB implements EntityBean {
> > public Integer KEY_ID;
> > public String NAME;
> > }
> >
> > I generate a sub class like this:
> >
> > package openejb.foo;
> > public class TestBeanEJB implements foo.TestBeanEJB {
> > }
> >
> > The entity mappings I use look like this:
> >
> >
> > xmlns="http://java.sun.com/xml/ns/persistence/orm";
> > version="1.0">
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > That all seems good, but when I deploy my bean I get the following
> > exception:
> >
> > INFO [Thread-10] openjpa.MetaData - Parsing package
> > "openejb.foo.TestBean".
> > TRACE [Thread-10] openjpa.MetaData - An exception occurred while
> > parsing jar:file:/tmp/OpenEJB_Generated_1334.jar!/META-INF/openejb-
> > cmp-generated-orm.xml at location Line: 7, C: 31. This exception
> > has been translated to a SAXException, and will be re-thrown. The
> > original exception is being logged along with this message.
> > java.lang.NoSuchFieldException: KEY_ID
> > at java.lang.Class.getDeclaredField(Class.java:1854)
> > at
> >
> org.apache.openjpa.persistence.XMLPersistenceMetaDataParser.pa
> rseField
> > (XMLPersistenceMetaDataParser.java:1079)
> > at
> > org.apache.openjpa.persistence.XMLPersistenceMetaDataParser.startId
> > (XMLPersistenceMetaDataParser.java:877)
> > at
> >
> org.apache.openjpa.persistence.XMLPersistenceMetaDataParser.st
> artClass
> > Element(XMLPersistenceMetaDataParser.java:543)
> > at org.apache.openjpa.lib.meta.CFMetaDataParser.startElement
> > (CFMetaDataParser.java:105)
> > at org.apache.openjpa.lib.meta.XMLMetaDataParser.startElement
> > (XMLMetaDataParser.java:426)
> > at org.apache.xerces.parsers.AbstractSAXParser.startElement
> > (Unknown Source)
> > at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement
> > (Unknown Source)
> > at
> > org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement
> > (Unknown Source)
> > at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl
> > $FragmentContentDispatcher.dispatch(Unknown Source)
> > at
> > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument
> > (Unknown Source)
> > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> > Source)
> > at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
> > Source)
> > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
> > Source)
> > at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
> > at
> > org.apache.openjpa.lib.meta.XMLMetaDataParser.parseNewResource
> > (XMLMetaDataParser.java:370)
> > at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse
> > (XMLMetaDataParser.java:312)
> > at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse
> > (XMLMetaDataParser.java:289)
> > at org.apache.openjpa.lib.m
RE: pessimistic locking
I think it's legit. In OpenJPA, to make this work in the intended manner, they should set openjpa.Optimistic to false and both openjpa.ReadLockLevel and openjpa.WriteLockLevel to 'none'. -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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, February 12, 2007 1:51 PM > To: open-jpa-dev@incubator.apache.org > Subject: Fwd: pessimistic locking > > Comments from the experts here? > > Craig > > > Begin forwarded message: > > > From: Scott Oaks <[EMAIL PROTECTED]> > Date: February 12, 2007 11:45:52 AM PST > To: [EMAIL PROTECTED] > Subject: pessimistic locking > Reply-To: [EMAIL PROTECTED] > > The SPEC organization is in the process of developing a > JPA-based > benchmark based on the CMP 2.1 implementation of > SPECjAppServer 2004. > Certain objects used in that benchmark are concurrently > modified by > multiple clients simultaneously; in order to score well on the > benchmark, pessimistic locking must be used on those entities. > Otherwise, the time spent rolling back and retrying the > operation (often > multiple times) is quite excessive. > > Realizing that pessimistic locking in the JPA spec is > non-portable, SPEC > intends to go this route: the highly-contended objects > will be obtained > this way: > > Customer c = em.getReference(Customer.class, 1); > em.lock(c, LockModeType.WRITE); > > And have the appserver vendor configure (though > deployment descriptors > or something else that doesn't modify the code) the > locks obtained that > way to be pessimistic locks. They have checked several JPA > implementations, all of whom say that they will be able > to support such > a feature (including, apparently, Toplink, though > AFAIK, that doesn't > apply to the subset of toplink in glassfish). > > This is a feature we would need quite soon; preferably > in 9.1 or at > least in an update soon after. What is the feasibility > of doing so? > > -Scott > > > Craig Russell > DB PMC > [EMAIL PROTECTED] http://db.apache.org/jdo > > >
[jira] Commented: (OPENJPA-141) More performance improvements (in response to changes for OPENJPA-138)
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472516
]
Kevin Sutter commented on OPENJPA-141:
--
> So what might work is having the keys be weak, and the otherwise unreferenced
> values strong. That way, the values will always be there as long as the keys
> are there. But if you do this, then you have to actually use the Class
> instances as keys, which implies solving the hashCode/equals problem.
Solving the hashcode/equals problem? You mean your concern about these
operations being slow? At least this caching is faster than repeating the
calls over and over again... :-)
It also seems that the ConcurrentReferenceHashMaps require at least one HARD
reference, so maybe your suggestion of WEAK/HARD is something to look at.
We're checking into it.
Thanks for the other suggestions on the isAssignable method as well.
More tomorrow...
> More performance improvements (in response to changes for OPENJPA-138)
> --
>
> Key: OPENJPA-141
> URL: https://issues.apache.org/jira/browse/OPENJPA-141
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
>Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> Abe's response to my committed changes for OPENJPA-138. I will be working
> with Abe and my performance team to work through these issues...
> > ==
> >
> > --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java (original)
> > +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> > @@ -29,6 +29,7 @@
> > implements ManagedRuntime {
> >
> > private String _tmLoc = "java:/TransactionManager";
> > +private static TransactionManager _tm;
> Whoa, I didn't think you meant caching the TM statically. That has
> to be backed out. You can cache it in an instance variable, but not
> statically. Nothing should prevent someone having two different
> BrokerFactories accessing two different TMs at two different JNDI
> locations.
> BrokerImpl:
> > + * Cache from/to assignments to avoid Class.isAssignableFrom
> > overhead
> > + * @param from the target Class
> > + * @param to the Class to test
> > + * @return true if the "to" class could be assigned to "from"
> > class
> > + */
> > +private boolean isAssignable(Class from, Class to) {
> > + boolean isAssignable;
> > + ConcurrentReferenceHashMap assignableTo =
> > + (ConcurrentReferenceHashMap) _assignableTypes.get(from);
> > +
> > + if (assignableTo != null) { // "to" cache exists...
> > + isAssignable = (assignableTo.get(to) != null);
> > + if (!isAssignable) { // not in the map yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + } else { // no "to" cache yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo = new ConcurrentReferenceHashMap(
> > + ReferenceMap.HARD, ReferenceMap.WEAK);
> > + _assignableTypes.put(from, assignableTo);
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + return isAssignable;
> > +}
> This code could be simplified a lot. Also, I don't understand what
> you're trying to do from a memory management perspective. For the
> _assignableTypes member you've got the Class keys using hard refs and
> the Map values using weak refs. No outside code references the Map
> values, so all entries should be eligible for GC pretty much
> immediately. The way reference hash maps work prevents them from
> expunging stale entries except on mutators, but still... every time a
> new entry is added, all the old entries should be getting GC'd and
> removed. Same for the individual Map values, which again map a hard
> class ref to an unreferenced object value with a weak ref. Basically
> the whole map-of-maps system should never contain more than one entry
> total after a GC run and a mutation.
> I'd really like to see you run your tests under a different JVM,
> because it seems to me like (a) this shouldn't be necessary in the
> first place, and (b) if this is working, it's again only because of
> some JVM particulars or GC timing particulars or testing particulars
> (I've seen profilers skew results in random ways like this) or even a
> bug in ConcurrentReferenceHashMap.
> The same goes for all the repeat logic in FetchConfigurationImpl.
> And if we keep this code or some vari
[jira] Commented: (OPENJPA-141) More performance improvements (in response to changes for OPENJPA-138)
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472510
]
Craig Russell commented on OPENJPA-141:
---
>> Craig thinks: Weak references are supposed to be cleaned up if the
>> referenced instance is not otherwise referenced. What would cause the
>> referred classes to be garbage collected immediately? I don't quite
>> understand the issue here.
>No, the current code holds the Classes with hard refs, and maps them to
>various values with weak refs. Nothing else refers to these weak values.
>Therefore they should be eligible for GC immediately, and their map entries
>should be removed on the next map mutation (reference maps only clean up their
>expired entries on mutation). That's why I don't understand how the current
>caches are working at all to boost performance, unless GC isn't happening very
>often.
Roger that. Thanks for the explanation, I'm now confused as well. :-(
So what might work is having the keys be weak, and the otherwise unreferenced
values strong. That way, the values will always be there as long as the keys
are there. But if you do this, then you have to actually use the Class
instances as keys, which implies solving the hashCode/equals problem.
> More performance improvements (in response to changes for OPENJPA-138)
> --
>
> Key: OPENJPA-141
> URL: https://issues.apache.org/jira/browse/OPENJPA-141
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
>Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> Abe's response to my committed changes for OPENJPA-138. I will be working
> with Abe and my performance team to work through these issues...
> > ==
> >
> > --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java (original)
> > +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> > @@ -29,6 +29,7 @@
> > implements ManagedRuntime {
> >
> > private String _tmLoc = "java:/TransactionManager";
> > +private static TransactionManager _tm;
> Whoa, I didn't think you meant caching the TM statically. That has
> to be backed out. You can cache it in an instance variable, but not
> statically. Nothing should prevent someone having two different
> BrokerFactories accessing two different TMs at two different JNDI
> locations.
> BrokerImpl:
> > + * Cache from/to assignments to avoid Class.isAssignableFrom
> > overhead
> > + * @param from the target Class
> > + * @param to the Class to test
> > + * @return true if the "to" class could be assigned to "from"
> > class
> > + */
> > +private boolean isAssignable(Class from, Class to) {
> > + boolean isAssignable;
> > + ConcurrentReferenceHashMap assignableTo =
> > + (ConcurrentReferenceHashMap) _assignableTypes.get(from);
> > +
> > + if (assignableTo != null) { // "to" cache exists...
> > + isAssignable = (assignableTo.get(to) != null);
> > + if (!isAssignable) { // not in the map yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + } else { // no "to" cache yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo = new ConcurrentReferenceHashMap(
> > + ReferenceMap.HARD, ReferenceMap.WEAK);
> > + _assignableTypes.put(from, assignableTo);
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + return isAssignable;
> > +}
> This code could be simplified a lot. Also, I don't understand what
> you're trying to do from a memory management perspective. For the
> _assignableTypes member you've got the Class keys using hard refs and
> the Map values using weak refs. No outside code references the Map
> values, so all entries should be eligible for GC pretty much
> immediately. The way reference hash maps work prevents them from
> expunging stale entries except on mutators, but still... every time a
> new entry is added, all the old entries should be getting GC'd and
> removed. Same for the individual Map values, which again map a hard
> class ref to an unreferenced object value with a weak ref. Basically
> the whole map-of-maps system should never contain more than one entry
> total after a GC run and a mutation.
> I'd really like to see you run your tests under a different JVM,
> because it seems to me like (a) this shouldn't be necessary in the
> first place, and
[jira] Commented: (OPENJPA-141) More performance improvements (in response to changes for OPENJPA-138)
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472506
]
Abe White commented on OPENJPA-141:
---
> Craig thinks: Weak references are supposed to be cleaned up if the referenced
> instance is not otherwise referenced. What would cause the referred classes
> to be garbage collected immediately? I don't quite understand the issue here.
No, the current code holds the Classes with hard refs, and maps them to various
values with weak refs. Nothing else refers to these weak values. Therefore
they should be eligible for GC immediately, and their map entries should be
removed on the next map mutation (reference maps only clean up their expired
entries on mutation). That's why I don't understand how the current caches are
working at all to boost performance, unless GC isn't happening very often.
> More performance improvements (in response to changes for OPENJPA-138)
> --
>
> Key: OPENJPA-141
> URL: https://issues.apache.org/jira/browse/OPENJPA-141
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
>Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> Abe's response to my committed changes for OPENJPA-138. I will be working
> with Abe and my performance team to work through these issues...
> > ==
> >
> > --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java (original)
> > +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> > @@ -29,6 +29,7 @@
> > implements ManagedRuntime {
> >
> > private String _tmLoc = "java:/TransactionManager";
> > +private static TransactionManager _tm;
> Whoa, I didn't think you meant caching the TM statically. That has
> to be backed out. You can cache it in an instance variable, but not
> statically. Nothing should prevent someone having two different
> BrokerFactories accessing two different TMs at two different JNDI
> locations.
> BrokerImpl:
> > + * Cache from/to assignments to avoid Class.isAssignableFrom
> > overhead
> > + * @param from the target Class
> > + * @param to the Class to test
> > + * @return true if the "to" class could be assigned to "from"
> > class
> > + */
> > +private boolean isAssignable(Class from, Class to) {
> > + boolean isAssignable;
> > + ConcurrentReferenceHashMap assignableTo =
> > + (ConcurrentReferenceHashMap) _assignableTypes.get(from);
> > +
> > + if (assignableTo != null) { // "to" cache exists...
> > + isAssignable = (assignableTo.get(to) != null);
> > + if (!isAssignable) { // not in the map yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + } else { // no "to" cache yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo = new ConcurrentReferenceHashMap(
> > + ReferenceMap.HARD, ReferenceMap.WEAK);
> > + _assignableTypes.put(from, assignableTo);
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + return isAssignable;
> > +}
> This code could be simplified a lot. Also, I don't understand what
> you're trying to do from a memory management perspective. For the
> _assignableTypes member you've got the Class keys using hard refs and
> the Map values using weak refs. No outside code references the Map
> values, so all entries should be eligible for GC pretty much
> immediately. The way reference hash maps work prevents them from
> expunging stale entries except on mutators, but still... every time a
> new entry is added, all the old entries should be getting GC'd and
> removed. Same for the individual Map values, which again map a hard
> class ref to an unreferenced object value with a weak ref. Basically
> the whole map-of-maps system should never contain more than one entry
> total after a GC run and a mutation.
> I'd really like to see you run your tests under a different JVM,
> because it seems to me like (a) this shouldn't be necessary in the
> first place, and (b) if this is working, it's again only because of
> some JVM particulars or GC timing particulars or testing particulars
> (I've seen profilers skew results in random ways like this) or even a
> bug in ConcurrentReferenceHashMap.
> The same goes for all the repeat logic in FetchConfigurationImpl.
> And if we keep this code or some variant of it, I strongly suggest
> moving it to a commo
Re: Do mapped superclasses work at all in OpenJPA?
Hi Dain, This might be related to a bug in xml overrides http:// issues.apache.org/jira/browse/OPENJPA-97. Just fer grins, do you have a way to annotate the mapped superclass? Craig On Feb 12, 2007, at 7:01 PM, Dain Sundstrom wrote: When I try to use a simple mapped super class with a trivial sub class (no fields or methods), I get the following exception: ERROR - The bean instances business method encountered a system exception:org.apache.openejb.test.entity.cmp.BasicCmpBean.pcGetManaged FieldCount()I java.lang.NoSuchMethodError: org.apache.openejb.test.entity.cmp.BasicCmpBean.pcGetManagedFieldCount ()I at openejb.org.apache.openejb.test.entity.cmp.BasicCmpBean. (Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.apache.openjpa.meta.MetaDataRepository.classForName (MetaDataRepository.java:1224) at org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypes (MetaDataRepository.java:1212) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings (JDBCBrokerFactory.java:145) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl (JDBCBrokerFactory.java:127) at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker (AbstractBrokerFactory.java:164) at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker (DelegatingBrokerFactory.java:139) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityMa nager(EntityManagerFactoryImpl.java:187) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityMa nager(EntityManagerFactoryImpl.java:52) at org.apache.openejb.persistence.JtaEntityManagerRegistry.getEntityManag er(JtaEntityManagerRegistry.java:105) Which seems to indicate to me that OpenJPA isn't enhancing the mapped super class. Does OpenJPA support mapped super classes? Here is are my entity mappings: http://java.sun.com/xml/ns/persistence/orm"; version="1.0"> class="org.apache.openejb.test.entity.cmp.BasicCmpBean"> class="openejb.org.apache.openejb.test.entity.cmp.BasicCmpBean"> BasicCmpBean Thanks for any help, -dain Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Do mapped superclasses work at all in OpenJPA?
When I try to use a simple mapped super class with a trivial sub class (no fields or methods), I get the following exception: ERROR - The bean instances business method encountered a system exception:org.apache.openejb.test.entity.cmp.BasicCmpBean.pcGetManagedFi eldCount()I java.lang.NoSuchMethodError: org.apache.openejb.test.entity.cmp.BasicCmpBean.pcGetManagedFieldCount ()I at openejb.org.apache.openejb.test.entity.cmp.BasicCmpBean. (Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.apache.openjpa.meta.MetaDataRepository.classForName (MetaDataRepository.java:1224) at org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypes (MetaDataRepository.java:1212) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings (JDBCBrokerFactory.java:145) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl (JDBCBrokerFactory.java:127) at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker (AbstractBrokerFactory.java:164) at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker (DelegatingBrokerFactory.java:139) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityMana ger(EntityManagerFactoryImpl.java:187) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityMana ger(EntityManagerFactoryImpl.java:52) at org.apache.openejb.persistence.JtaEntityManagerRegistry.getEntityManager (JtaEntityManagerRegistry.java:105) Which seems to indicate to me that OpenJPA isn't enhancing the mapped super class. Does OpenJPA support mapped super classes? Here is are my entity mappings: http://java.sun.com/xml/ns/persistence/orm"; version="1.0"> class="org.apache.openejb.test.entity.cmp.BasicCmpBean"> class="openejb.org.apache.openejb.test.entity.cmp.BasicCmpBean"> BasicCmpBean Thanks for any help, -dain
Re: NoSuchFieldException
I think I need to declare a mapped-superclass, and then use attribute-
overrides in the subclass.
Does anyone know if I can declare a mapped-superclass with all fields
declared as transient and then use attribute-override in the subclass
for fields I want to map? I would be easier for me to code it that
way (and yes I am quite lazy).
-dain
On Feb 12, 2007, at 4:00 PM, Dain Sundstrom wrote:
I have this scenario in my CMP2JPA tool where I have to generate
subclasses of CMP1 beans. When the user has an "unknown" primary
key or more commonly, when they use the same ejb class for multiple
deployments, I have to generate a sub class to either add an extra
field, or to differentiate two usages of the same class. So say I
have the class "foo.TestBean", like this:
package foo;
public class TestBeanEJB implements EntityBean {
public Integer KEY_ID;
public String NAME;
}
I generate a sub class like this:
package openejb.foo;
public class TestBeanEJB implements foo.TestBeanEJB {
}
The entity mappings I use look like this:
http://java.sun.com/xml/ns/persistence/orm";
version="1.0">
That all seems good, but when I deploy my bean I get the following
exception:
INFO [Thread-10] openjpa.MetaData - Parsing package
"openejb.foo.TestBean".
TRACE [Thread-10] openjpa.MetaData - An exception occurred while
parsing jar:file:/tmp/OpenEJB_Generated_1334.jar!/META-INF/openejb-
cmp-generated-orm.xml at location Line: 7, C: 31. This exception
has been translated to a SAXException, and will be re-thrown. The
original exception is being logged along with this message.
java.lang.NoSuchFieldException: KEY_ID
at java.lang.Class.getDeclaredField(Class.java:1854)
at
org.apache.openjpa.persistence.XMLPersistenceMetaDataParser.parseField
(XMLPersistenceMetaDataParser.java:1079)
at
org.apache.openjpa.persistence.XMLPersistenceMetaDataParser.startId
(XMLPersistenceMetaDataParser.java:877)
at
org.apache.openjpa.persistence.XMLPersistenceMetaDataParser.startClass
Element(XMLPersistenceMetaDataParser.java:543)
at org.apache.openjpa.lib.meta.CFMetaDataParser.startElement
(CFMetaDataParser.java:105)
at org.apache.openjpa.lib.meta.XMLMetaDataParser.startElement
(XMLMetaDataParser.java:426)
at org.apache.xerces.parsers.AbstractSAXParser.startElement
(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement
(Unknown Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement
(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl
$FragmentContentDispatcher.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument
(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown
Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
Source)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at
org.apache.openjpa.lib.meta.XMLMetaDataParser.parseNewResource
(XMLMetaDataParser.java:370)
at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse
(XMLMetaDataParser.java:312)
at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse
(XMLMetaDataParser.java:289)
at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse
(XMLMetaDataParser.java:263)
at
org.apache.openjpa.persistence.PersistenceMetaDataFactory.parseXML
(PersistenceMetaDataFactory.java:229)
at
org.apache.openjpa.persistence.PersistenceMetaDataFactory.load
(PersistenceMetaDataFactory.java:180)
at
org.apache.openjpa.meta.MetaDataRepository.getMetaDataInternal
(MetaDataRepository.java:412)
at org.apache.openjpa.meta.MetaDataRepository.getMetaData
(MetaDataRepository.java:270)
at org.apache.openjpa.enhance.PCEnhancer.(PCEnhancer.java:
187)
at org.apache.openjpa.enhance.PCClassFileTransformer.transform
(PCClassFileTransformer.java:124)
at org.apache.openjpa.persistence.PersistenceProviderImpl
$ClassTransformerImpl.transform(PersistenceProviderImpl.java:140)
at org.apache.openejb.persistence.PersistenceUnitInfoImpl
$PersistenceClassFileTransformer.transform
(PersistenceUnitInfoImpl.java:259)
Note: the exception should at least tell us which class had the
problem :)
Is there some magic flag for JPA that, I can use to make it look in
the super class fields persistent fields?
-dain
[jira] Commented: (OPENJPA-141) More performance improvements (in response to changes for OPENJPA-138)
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472478
]
Craig Russell commented on OPENJPA-141:
---
Abe opined:
1. Each BrokerFactory has a ManagedRuntime. You can have multiple
BrokerFactories, each of which is supposed to be completely independent.
Therefore you can have multiple ManagedRuntimes, each of which is supposed to
be completely independent. Caching the TM in a static in JNDIManagedRuntime
breaks that.
Craig thinks: +1. There is no reason to optimize the number of lookups of the
ManagedRuntime, since it's only done once per EMF creation. I agree that making
the reference static goes too far.
2. I still don't understand how the caches were working at all with the weak
refs, unless GC just wasn't kicking in very often. Any info on this?
Craig thinks: Weak references are supposed to be cleaned up if the referenced
instance is not otherwise referenced. What would cause the referred classes to
be garbage collected immediately? I don't quite understand the issue here.
But this might beg the real issue, which is what to use as the key for the Map
if you want to effectively use the Class as the key but the hashCode and equals
methods are just too slow. It might be well to look more closely at
IdentityHashMap, in particular to see if there exists a
ConcurrentIdentityHashMap or if we can create one. The IdentityHashMap uses
System.identityHashCode(Object) instead of the overridden hashCode and ==
instead of equals. Even with Class instances as keys, this kind of Map should
perform well.
I also don't understand all the logic when caching the assignableTo info.
> + if (isAssignable) {
> + assignableTo.put(to, new Object());
Seems like you would want to cache all instances of To and From, whether or not
the answer is True. Once anyone asks if two types are assignable, and you find
out the answer, why not cache the answer? From the code, it looks like you only
cache True results. What if you change the above code to:
Boolean isAssignableResult = Boolean.valueOf(isAssignable);
assignableTo.put(to, isAssignableResult);
> More performance improvements (in response to changes for OPENJPA-138)
> --
>
> Key: OPENJPA-141
> URL: https://issues.apache.org/jira/browse/OPENJPA-141
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
>Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> Abe's response to my committed changes for OPENJPA-138. I will be working
> with Abe and my performance team to work through these issues...
> > ==
> >
> > --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java (original)
> > +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> > @@ -29,6 +29,7 @@
> > implements ManagedRuntime {
> >
> > private String _tmLoc = "java:/TransactionManager";
> > +private static TransactionManager _tm;
> Whoa, I didn't think you meant caching the TM statically. That has
> to be backed out. You can cache it in an instance variable, but not
> statically. Nothing should prevent someone having two different
> BrokerFactories accessing two different TMs at two different JNDI
> locations.
> BrokerImpl:
> > + * Cache from/to assignments to avoid Class.isAssignableFrom
> > overhead
> > + * @param from the target Class
> > + * @param to the Class to test
> > + * @return true if the "to" class could be assigned to "from"
> > class
> > + */
> > +private boolean isAssignable(Class from, Class to) {
> > + boolean isAssignable;
> > + ConcurrentReferenceHashMap assignableTo =
> > + (ConcurrentReferenceHashMap) _assignableTypes.get(from);
> > +
> > + if (assignableTo != null) { // "to" cache exists...
> > + isAssignable = (assignableTo.get(to) != null);
> > + if (!isAssignable) { // not in the map yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + } else { // no "to" cache yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo = new ConcurrentReferenceHashMap(
> > + ReferenceMap.HARD, ReferenceMap.WEAK);
> > + _assignableTypes.put(from, assignableTo);
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + return isAssignable;
> > +}
> This code could be simplified a lot. Also, I don't understand what
> y
NoSuchFieldException
I have this scenario in my CMP2JPA tool where I have to generate
subclasses of CMP1 beans. When the user has an "unknown" primary key
or more commonly, when they use the same ejb class for multiple
deployments, I have to generate a sub class to either add an extra
field, or to differentiate two usages of the same class. So say I
have the class "foo.TestBean", like this:
package foo;
public class TestBeanEJB implements EntityBean {
public Integer KEY_ID;
public String NAME;
}
I generate a sub class like this:
package openejb.foo;
public class TestBeanEJB implements foo.TestBeanEJB {
}
The entity mappings I use look like this:
http://java.sun.com/xml/ns/persistence/orm";
version="1.0">
That all seems good, but when I deploy my bean I get the following
exception:
INFO [Thread-10] openjpa.MetaData - Parsing package
"openejb.foo.TestBean".
TRACE [Thread-10] openjpa.MetaData - An exception occurred while
parsing jar:file:/tmp/OpenEJB_Generated_1334.jar!/META-INF/openejb-
cmp-generated-orm.xml at location Line: 7, C: 31. This exception has
been translated to a SAXException, and will be re-thrown. The
original exception is being logged along with this message.
java.lang.NoSuchFieldException: KEY_ID
at java.lang.Class.getDeclaredField(Class.java:1854)
at
org.apache.openjpa.persistence.XMLPersistenceMetaDataParser.parseField
(XMLPersistenceMetaDataParser.java:1079)
at
org.apache.openjpa.persistence.XMLPersistenceMetaDataParser.startId
(XMLPersistenceMetaDataParser.java:877)
at
org.apache.openjpa.persistence.XMLPersistenceMetaDataParser.startClassEl
ement(XMLPersistenceMetaDataParser.java:543)
at org.apache.openjpa.lib.meta.CFMetaDataParser.startElement
(CFMetaDataParser.java:105)
at org.apache.openjpa.lib.meta.XMLMetaDataParser.startElement
(XMLMetaDataParser.java:426)
at org.apache.xerces.parsers.AbstractSAXParser.startElement
(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement
(Unknown Source)
at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement
(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl
$FragmentContentDispatcher.dispatch(Unknown Source)
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument
(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
Source)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at org.apache.openjpa.lib.meta.XMLMetaDataParser.parseNewResource
(XMLMetaDataParser.java:370)
at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse
(XMLMetaDataParser.java:312)
at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse
(XMLMetaDataParser.java:289)
at org.apache.openjpa.lib.meta.XMLMetaDataParser.parse
(XMLMetaDataParser.java:263)
at
org.apache.openjpa.persistence.PersistenceMetaDataFactory.parseXML
(PersistenceMetaDataFactory.java:229)
at org.apache.openjpa.persistence.PersistenceMetaDataFactory.load
(PersistenceMetaDataFactory.java:180)
at org.apache.openjpa.meta.MetaDataRepository.getMetaDataInternal
(MetaDataRepository.java:412)
at org.apache.openjpa.meta.MetaDataRepository.getMetaData
(MetaDataRepository.java:270)
at org.apache.openjpa.enhance.PCEnhancer.(PCEnhancer.java:
187)
at org.apache.openjpa.enhance.PCClassFileTransformer.transform
(PCClassFileTransformer.java:124)
at org.apache.openjpa.persistence.PersistenceProviderImpl
$ClassTransformerImpl.transform(PersistenceProviderImpl.java:140)
at org.apache.openejb.persistence.PersistenceUnitInfoImpl
$PersistenceClassFileTransformer.transform
(PersistenceUnitInfoImpl.java:259)
Note: the exception should at least tell us which class had the
problem :)
Is there some magic flag for JPA that, I can use to make it look in
the super class fields persistent fields?
-dain
[jira] Commented: (OPENJPA-141) More performance improvements (in response to changes for OPENJPA-138)
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472455
]
Abe White commented on OPENJPA-141:
---
1. Each BrokerFactory has a ManagedRuntime. You can have multiple
BrokerFactories, each of which is supposed to be completely independent.
Therefore you can have multiple ManagedRuntimes, each of which is supposed to
be completely independent. Caching the TM in a static in JNDIManagedRuntime
breaks that.
2. I still don't understand how the caches were working at all with the weak
refs, unless GC just wasn't kicking in very often. Any info on this?
As to the proposed changes: there's no point in caching on Class keys with soft
refs. As soon as a Class is no longer referenced anywhere, there's no point in
keeping it around. So all Class keys should be weak refs. The corresponding
values can be soft.
3. System.identityHashCode isn't going to help with superclasses... I didn't
realize that that was the slow part.
> More performance improvements (in response to changes for OPENJPA-138)
> --
>
> Key: OPENJPA-141
> URL: https://issues.apache.org/jira/browse/OPENJPA-141
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
>Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> Abe's response to my committed changes for OPENJPA-138. I will be working
> with Abe and my performance team to work through these issues...
> > ==
> >
> > --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java (original)
> > +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> > @@ -29,6 +29,7 @@
> > implements ManagedRuntime {
> >
> > private String _tmLoc = "java:/TransactionManager";
> > +private static TransactionManager _tm;
> Whoa, I didn't think you meant caching the TM statically. That has
> to be backed out. You can cache it in an instance variable, but not
> statically. Nothing should prevent someone having two different
> BrokerFactories accessing two different TMs at two different JNDI
> locations.
> BrokerImpl:
> > + * Cache from/to assignments to avoid Class.isAssignableFrom
> > overhead
> > + * @param from the target Class
> > + * @param to the Class to test
> > + * @return true if the "to" class could be assigned to "from"
> > class
> > + */
> > +private boolean isAssignable(Class from, Class to) {
> > + boolean isAssignable;
> > + ConcurrentReferenceHashMap assignableTo =
> > + (ConcurrentReferenceHashMap) _assignableTypes.get(from);
> > +
> > + if (assignableTo != null) { // "to" cache exists...
> > + isAssignable = (assignableTo.get(to) != null);
> > + if (!isAssignable) { // not in the map yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + } else { // no "to" cache yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo = new ConcurrentReferenceHashMap(
> > + ReferenceMap.HARD, ReferenceMap.WEAK);
> > + _assignableTypes.put(from, assignableTo);
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + return isAssignable;
> > +}
> This code could be simplified a lot. Also, I don't understand what
> you're trying to do from a memory management perspective. For the
> _assignableTypes member you've got the Class keys using hard refs and
> the Map values using weak refs. No outside code references the Map
> values, so all entries should be eligible for GC pretty much
> immediately. The way reference hash maps work prevents them from
> expunging stale entries except on mutators, but still... every time a
> new entry is added, all the old entries should be getting GC'd and
> removed. Same for the individual Map values, which again map a hard
> class ref to an unreferenced object value with a weak ref. Basically
> the whole map-of-maps system should never contain more than one entry
> total after a GC run and a mutation.
> I'd really like to see you run your tests under a different JVM,
> because it seems to me like (a) this shouldn't be necessary in the
> first place, and (b) if this is working, it's again only because of
> some JVM particulars or GC timing particulars or testing particulars
> (I've seen profilers skew results in random ways like this) or even a
> bug in ConcurrentReferenceHashMap.
> The same goes for all the r
Re: Kodo passes JPA tck
Yes, the problem is that it's not publicly visible. I need to solve that... On Feb 12, 2007, at 5:37 PM, robert burrell donkin wrote: On 2/12/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Feb 12, 2007, at 4:33 PM, Marc Prud'hommeaux wrote: > Dain- > > I've been working on the TCK certification for OpenJPA. The terms > of Sun's TCK license dictate that I can't discuss the details with > any people who haven't signed Apache's NDA (see http:// > www.apache.org/jcp/), but I can say that we might be able to make > an announcement regarding compliance sometime soon. Dain has signed the NDA. don't we have a list somewhere or other for discussions of this kind...? - robert
Re: Kodo passes JPA tck
On 2/12/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: On Feb 12, 2007, at 4:33 PM, Marc Prud'hommeaux wrote: > Dain- > > I've been working on the TCK certification for OpenJPA. The terms > of Sun's TCK license dictate that I can't discuss the details with > any people who haven't signed Apache's NDA (see http:// > www.apache.org/jcp/), but I can say that we might be able to make > an announcement regarding compliance sometime soon. Dain has signed the NDA. don't we have a list somewhere or other for discussions of this kind...? - robert
[jira] Commented: (OPENJPA-141) More performance improvements (in response to changes for OPENJPA-138)
[
https://issues.apache.org/jira/browse/OPENJPA-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472440
]
Kevin Sutter commented on OPENJPA-141:
--
Re: Caching the TransactionManager in a static...
Although we could cache the TM in an instance variable or even do a hashmap
with the name as the key, I'm wondering what the scenario is where we could
have multiple TMs at different JNDI locations. I've looked at the code and it
seems that we have a single TM per runtime instance and we have one of those
per configuration. We attempt to find or create an appropriate runtime
instance which in turn creates an appropriate TM. Where or how can we run into
the multiple TM problem?
Re: Caching of the assignable from/to types
Yeah, the HARD/WEAK reference types probably weren't the right choices. For
the outer map, we could change to SOFT/SOFT references, and the inner map we
could change to SOFT/WEAK references (since we don't really care about the
values in the inner map). We'll do some experimenting with this to determine
the proper configuration.
Moving this common "isAssignable" code to ImplHelper or something similar is a
good suggestion. I had the same thoughts, but ran out of time over the
weekend...
Re: Use a different JVM
We are actually doing these performance runs using the Sun JDK. We are also
verifying the results with the IBM JDK, but the Sun JDK is the one used for the
primary performance runs and analysis.
Re: Hashcode performance
It's actually not the calls to Class.hashCode() that take up so much time, it's
the calls to Class.getSuperClass() that we're trying to avoid. I'm not
familiar with the System.identityHashCode() method. Maybe this method does the
proper getSuperClass processing more efficiently? Not sure.
Also, same comment about the HARD/WEAK references. I'll probably end up
changing that to SOFT/SOFT.
Re: Class.getClassLoader performance
Unfortunately, this call is expensive. Although in theory, this invocation
should be cheap since each Class needs a reference to its ClassLoader, the
caching of the ClassLoader is beneficial. Here again, this is with the Sun JDK
as our primary JVM.
Re: Overall
As stated previously, we are using the Sun JDK for all of these performance
benchmarks. We also verify the results using the IBM JDK. (We've even done
some comparisons with JRockit.) I've asked our performance team to generalize
our results for consumption by the OpenJPA community (we're not ready to go
public with any specific numbers). I should be able to post something shortly.
Thanks,
Kevin
> More performance improvements (in response to changes for OPENJPA-138)
> --
>
> Key: OPENJPA-141
> URL: https://issues.apache.org/jira/browse/OPENJPA-141
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
>Reporter: Kevin Sutter
> Assigned To: Kevin Sutter
>
> Abe's response to my committed changes for OPENJPA-138. I will be working
> with Abe and my performance team to work through these issues...
> > ==
> >
> > --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java (original)
> > +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> > openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> > @@ -29,6 +29,7 @@
> > implements ManagedRuntime {
> >
> > private String _tmLoc = "java:/TransactionManager";
> > +private static TransactionManager _tm;
> Whoa, I didn't think you meant caching the TM statically. That has
> to be backed out. You can cache it in an instance variable, but not
> statically. Nothing should prevent someone having two different
> BrokerFactories accessing two different TMs at two different JNDI
> locations.
> BrokerImpl:
> > + * Cache from/to assignments to avoid Class.isAssignableFrom
> > overhead
> > + * @param from the target Class
> > + * @param to the Class to test
> > + * @return true if the "to" class could be assigned to "from"
> > class
> > + */
> > +private boolean isAssignable(Class from, Class to) {
> > + boolean isAssignable;
> > + ConcurrentReferenceHashMap assignableTo =
> > + (ConcurrentReferenceHashMap) _assignableTypes.get(from);
> > +
> > + if (assignableTo != null) { // "to" cache exists...
> > + isAssignable = (assignableTo.get(to) != null);
> > + if (!isAssignable) { // not in the map yet...
> > + isAssignable = from.isAssignableFrom(to);
> > + if (isAssignable) {
> > + assignableTo.put(to, new Object());
> > + }
> > + }
> > + } else { // no "to" cache yet...
> > +
Fwd: pessimistic locking
Comments from the experts here? Craig Begin forwarded message: From: Scott Oaks <[EMAIL PROTECTED]> Date: February 12, 2007 11:45:52 AM PST To: [EMAIL PROTECTED] Subject: pessimistic locking Reply-To: [EMAIL PROTECTED] The SPEC organization is in the process of developing a JPA-based benchmark based on the CMP 2.1 implementation of SPECjAppServer 2004. Certain objects used in that benchmark are concurrently modified by multiple clients simultaneously; in order to score well on the benchmark, pessimistic locking must be used on those entities. Otherwise, the time spent rolling back and retrying the operation (often multiple times) is quite excessive. Realizing that pessimistic locking in the JPA spec is non-portable, SPEC intends to go this route: the highly-contended objects will be obtained this way: Customer c = em.getReference(Customer.class, 1); em.lock(c, LockModeType.WRITE); And have the appserver vendor configure (though deployment descriptors or something else that doesn't modify the code) the locks obtained that way to be pessimistic locks. They have checked several JPA implementations, all of whom say that they will be able to support such a feature (including, apparently, Toplink, though AFAIK, that doesn't apply to the subset of toplink in glassfish). This is a feature we would need quite soon; preferably in 9.1 or at least in an update soon after. What is the feasibility of doing so? -Scott Craig Russell DB PMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: Kodo passes JPA tck
On Feb 12, 2007, at 4:33 PM, Marc Prud'hommeaux wrote: Dain- I've been working on the TCK certification for OpenJPA. The terms of Sun's TCK license dictate that I can't discuss the details with any people who haven't signed Apache's NDA (see http:// www.apache.org/jcp/), but I can say that we might be able to make an announcement regarding compliance sometime soon. Dain has signed the NDA. PS. If you are NDA'd, and you have access to the JPA TCK files, you can run the TCK compliance tests against OpenJPA yourself by running "mvn integration-test". On Feb 12, 2007, at 1:05 PM, Dain Sundstrom wrote: I read on the serverside.com that Kodo has passed the JPA tck, and am curious if there are any uncommitted patches from BEA that are required to make OpenJPA compliant. Also, has anyone run OpenJPA through the JPA tck and if so did we pass? -dain
Re: Kodo passes JPA tck
Dain- I've been working on the TCK certification for OpenJPA. The terms of Sun's TCK license dictate that I can't discuss the details with any people who haven't signed Apache's NDA (see http://www.apache.org/ jcp/), but I can say that we might be able to make an announcement regarding compliance sometime soon. PS. If you are NDA'd, and you have access to the JPA TCK files, you can run the TCK compliance tests against OpenJPA yourself by running "mvn integration-test". On Feb 12, 2007, at 1:05 PM, Dain Sundstrom wrote: I read on the serverside.com that Kodo has passed the JPA tck, and am curious if there are any uncommitted patches from BEA that are required to make OpenJPA compliant. Also, has anyone run OpenJPA through the JPA tck and if so did we pass? -dain
Kodo passes JPA tck
I read on the serverside.com that Kodo has passed the JPA tck, and am curious if there are any uncommitted patches from BEA that are required to make OpenJPA compliant. Also, has anyone run OpenJPA through the JPA tck and if so did we pass? -dain
Re: [VOTE] Move JPA API dependency from dev.java.net to geronimo version
+1 ...because of the compliance reasons you outlined. Michael Dick wrote: +1 On 2/10/07, Eddie O'Neil <[EMAIL PROTECTED]> wrote: +1 On 2/9/07, Craig L Russell <[EMAIL PROTECTED]> wrote: > +1 > > My vote is as much related to dissatisfaction with the maven repo > that is used by glassfish as with the time it takes to get anything > done through official channels. > > Craig > > On Feb 8, 2007, at 9:41 PM, Marc Prud'hommeaux wrote: > > > > > It turns out that the JPA API we've been building against (the one > > from https://maven-repository.dev.java.net/repository/ > > javax.persistence/jars/persistence-api-1.0.jar) is not actually the > > final version of the spec: there are some minor (and binary- > > compatible) changes (some annotations don't have runtime retention, > > for example), but they are enough to prevent us from passing all > > the compatibility tests we need. > > > > The Geronimo API jar (http://mirrors.ibiblio.org/pub/mirrors/maven2/ > > org/apache/geronimo/specs/geronimo-jpa_3.0_spec/geronimo- > > jpa_3.0_spec-1.0.jar) is compliant, as far as I can tell. > > > > How do people feel about changing the dependency from persistence- > > api-1.0.jar to geronimo-jpa_3.0_spec-1.0.jar? I've run through all > > our tests, and they pass with the Geronimo version. This would have > > the added advantage of unifying our spec jars to all be using the > > Geronimo versions. > > > > +1 indicates that you approve of the change > > -1 indicated that you disagree that the change should be made > > > > > > > > > > > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > > >
Entity name ignored in queries (0.9.6)?
I'm using 0.9.6 and it appears the OpenJPA is ignoring the entity
name when processing queries. In stead it seems to always choose the
class name for the schema name of the bean. For example, I have the
following bean declared in my entity mappings:
class="org.apache.openejb.test.entity.cmp.BasicCmp2Bean_BasicCmp2Bean">
BasicCmp2Bean
The following query does not work:
SELECT o FROM BasicCmp2Bean o WHERE o.lastName = ?1
But this one does:
SELECT o FROM BasicCmp2Bean_BasicCmp2Bean o WHERE o.lastName
= ?1
When the query fails, I get this message (reformatted a bit with **
added to important entries):
ERROR - The bean instances business method encountered a system
exception: Could not locate metadata for the class using alias
"BasicCmp2Bean". Registered alias mappings: "{
AllowedOperationsCmp2Bean_AOBasicCmp2Bean=
[class
org.apache.openejb.test.entity.cmp.AllowedOperationsCmp2Bean_AOBasicCmp2
Bean],
AllowedOperationsCmpBean=
[class org.apache.openejb.test.entity.cmp.AllowedOperationsCmpBean],
ContextLookupCmpBean=
[class org.apache.openejb.test.entity.cmp.ContextLookupCmpBean],
Employee=
[class org.apache.openejb.test.entity.cmp2.Employee],
ManyOwningSideBean_ManyOwningSideBean=
[class
org.apache.openejb.test.entity.cmr.cmrmapping.ManyOwningSideBean_ManyOwn
ingSideBean],
**BasicCmp2Bean_BasicCmp2Bean=
[class
org.apache.openejb.test.entity.cmp.BasicCmp2Bean_BasicCmp2Bean],
EncCmpBean=
[class org.apache.openejb.test.entity.cmp.EncCmpBean],
BBean_OneToOneB=
[class org.apache.openejb.test.entity.cmr.onetoone.BBean_OneToOneB],
OneOwningSideBean_OneOwningSideBean=
[class
org.apache.openejb.test.entity.cmr.cmrmapping.OneOwningSideBean_OneOwnin
gSideBean],
ABean_OneToOneA=
[class org.apache.openejb.test.entity.cmr.onetoone.ABean_OneToOneA],
**BasicCmp2Bean=null,
RmiIiopCmpBean=
[class org.apache.openejb.test.entity.cmp.RmiIiopCmpBean],
ABean_OneToManyA=
[class
org.apache.openejb.test.entity.cmr.onetomany.ABean_OneToManyA],
OneInverseSideBean_OneInverseSideBean=
[class
org.apache.openejb.test.entity.cmr.cmrmapping.OneInverseSideBean_OneInve
rseSideBean],
BBean_OneToManyB=
[class
org.apache.openejb.test.entity.cmr.onetomany.BBean_OneToManyB],
RmiIiopCmp2Bean_Cmp2_RMI_IIOP_Bean=
[class
org.apache.openejb.test.entity.cmp.RmiIiopCmp2Bean_Cmp2_RMI_IIOP_Bean],
EncCmp2Bean_EncCmp2Bean=
[class org.apache.openejb.test.entity.cmp.EncCmp2Bean_EncCmp2Bean],
BasicCmpBean=
[class org.apache.openejb.test.entity.cmp.BasicCmpBean]}"
I kind of remember Patrick fixing a bug like this but I couldn't find
the email.
-dain
Re: [VOTE] Move JPA API dependency from dev.java.net to geronimo version
+1 On 2/10/07, Eddie O'Neil <[EMAIL PROTECTED]> wrote: +1 On 2/9/07, Craig L Russell <[EMAIL PROTECTED]> wrote: > +1 > > My vote is as much related to dissatisfaction with the maven repo > that is used by glassfish as with the time it takes to get anything > done through official channels. > > Craig > > On Feb 8, 2007, at 9:41 PM, Marc Prud'hommeaux wrote: > > > > > It turns out that the JPA API we've been building against (the one > > from https://maven-repository.dev.java.net/repository/ > > javax.persistence/jars/persistence-api-1.0.jar) is not actually the > > final version of the spec: there are some minor (and binary- > > compatible) changes (some annotations don't have runtime retention, > > for example), but they are enough to prevent us from passing all > > the compatibility tests we need. > > > > The Geronimo API jar (http://mirrors.ibiblio.org/pub/mirrors/maven2/ > > org/apache/geronimo/specs/geronimo-jpa_3.0_spec/geronimo- > > jpa_3.0_spec-1.0.jar) is compliant, as far as I can tell. > > > > How do people feel about changing the dependency from persistence- > > api-1.0.jar to geronimo-jpa_3.0_spec-1.0.jar? I've run through all > > our tests, and they pass with the Geronimo version. This would have > > the added advantage of unifying our spec jars to all be using the > > Geronimo versions. > > > > +1 indicates that you approve of the change > > -1 indicated that you disagree that the change should be made > > > > > > > > > > > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > > > -- -Michael Dick
Re: Strange, intermittent problem running the new models.company tests
That clarification works for me... ;-) On 2/12/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: Kevin- It could, but it would just be a spec compliance. OpenJPA does allow you to have final classes. The spec just prohibits it because one of the ways to implement support for property access is to dynamically generate a subclass to the entity (which isn't possible if the entity is final). On Feb 12, 2007, at 4:33 AM, Kevin Sutter wrote: > Marc (and others), > Shouldn't OpenJPA be detecting these final classes and issuing an > error > message? > > Kevin > > On 2/12/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: >> >> Craig- >> >> You're right that the classes shouldn't be final, but I don't think >> that's the cause of the problem. >> >> I've committed a fix to the final class issue, though. Thanks for >> pointing it out. >> >> >> >> On Feb 10, 2007, at 10:07 PM, Craig L Russell wrote: >> >> > Hi Kevin, >> > >> > I don't know if it's relevant, but persistent classes must not be >> > final. It seems that the entities in the model.company packages are >> > (all) final, which is wrong. From spec 2.1, "The entity class must >> > not be final. No methods or persistent instance variables of the >> > entity class may be final. " >> > >> > The relevant part of the stack trace appears to be: >> >> Caused by: java.lang.NoSuchMethodException: =Class.create >> >> (Class); >> >>at java.beans.Statement.invoke(Statement.java:269) >> >>at .(Unknown Source) >> >>at com.sun.beans.ObjectHandler.eval(ObjectHandler.java:148) >> >>at com.sun.beans.ObjectHandler.startElement >> >> (ObjectHandler.java:250) >> >>at org.apache.xerces.parsers.AbstractSAXParser.startElement >> >> (Unknown >> >> Source) >> >>at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement >> >> (Unknown >> > >> > which sounds like an issue with the xerces parser. Don't you hate >> > exceptions from parsers rather than error messages? >> > >> > Craig >> > >> > On Feb 10, 2007, at 8:08 PM, Kevin Sutter wrote: >> > >> >> Marc, >> >> It took a while to reproduce, but I finally got the following... >> >> Does this >> >> help? Thanks for your help! >> >> >> >> Kevin >> >> >> >> Running >> >> >> org.apache.openjpa.persistence.models.company.propertyaccess.TestProp >> >> ertyCompanyModel >> >> 0 test INFO [main] openjpa.Runtime - Starting OpenJPA 0.0.0 >> >> 0 test INFO [main] openjpa.jdbc.JDBC - OpenJPA will now >> >> connect to the >> >> database to attempt to determine what type of database dictionary >> >> to use. >> >> To prevent this connection in the future, set your >> >> openjpa.jdbc.DBDictionaryconfiguration property to the appropriate >> >> value for your database (see the >> >> documentation foravailable values). >> >> 0 test INFO [main] openjpa.jdbc.JDBC - Using dictionary >> class " >> >> org.apache.openjpa.jdbc.sql.DerbyDictionary" (Apache Derby >> 10.2.2.0 - >> >> (485682) ,Apache Derby >> >> Embedded JDBC Driver 10.2.2.0 - (485682)). >> >> 10 test INFO [main] openjpa.MetaData - Found 10 classes with >> >> metadata in >> >> 0 milliseconds. >> >> 20 test INFO [main] openjpa.MetaData - Found 10 classes with >> >> metadata in >> >> 10 milliseconds. >> >> 20 test INFO [main] openjpa.MetaData - Parsing class " >> >> >> org.apache.openjpa.persistence.models.company.propertyaccess.Product" >> >> . >> >> 20 test INFO [main] openjpa.MetaData - Parsing package " >> >> >> org.apache.openjpa.persistence.models.company.propertyaccess.Product" >> >> . >> >> 30 test INFO [main] openjpa.MetaData - Parsing class " >> >> >> org.apache.openjpa.persistence.models.company.propertyaccess.Company" >> >> . >> >> 30 test INFO [main] openjpa.MetaData - Parsing class " >> >> >> org.apache.openjpa.persistence.models.company.propertyaccess.Address" >> >> . >> >> 40 test INFO [main] openjpa.MetaData - Parsing class " >> >> >> org.apache.openjpa.persistence.models.company.propertyaccess.Employee >> >> ". >> >> 40 test INFO [main] openjpa.MetaData - Parsing class " >> >> >> org.apache.openjpa.persistence.models.company.propertyaccess.Person". >> >> 50 test INFO [main] openjpa.MetaData - Parsing class " >> >> >> org.apache.openjpa.persistence.models.company.propertyaccess.FullTime >> >> Employee >> >> ". >> >> 50 test INFO [main] openjpa.MetaData - Parsing class " >> >> >> org.apache.openjpa.persistence.models.company.propertyaccess.LineItem >> >> ". >> >> 60 test INFO [main] openjpa.MetaData - Parsing class " >> >> >> org.apache.openjpa.persistence.models.company.propertyaccess.ProductO >> >> rder". >> >> 60 test INFO [main] openjpa.MetaData - Parsing class " >> >> >> org.apache.openjpa.persistence.models.company.propertyaccess.Customer >> >> ". >> >> 70 test INFO [main] openjpa.MetaData - Parsing class " >> >> >> org.apache.openjpa.persistence.models.company.propertyaccess.PartTime >> >> Employee >> >> ". >> >> 70 test INFO [main] openjpa.jdbc.Schema - R
Re: Strange, intermittent problem running the new models.company tests
Kevin- It could, but it would just be a spec compliance. OpenJPA does allow you to have final classes. The spec just prohibits it because one of the ways to implement support for property access is to dynamically generate a subclass to the entity (which isn't possible if the entity is final). On Feb 12, 2007, at 4:33 AM, Kevin Sutter wrote: Marc (and others), Shouldn't OpenJPA be detecting these final classes and issuing an error message? Kevin On 2/12/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: Craig- You're right that the classes shouldn't be final, but I don't think that's the cause of the problem. I've committed a fix to the final class issue, though. Thanks for pointing it out. On Feb 10, 2007, at 10:07 PM, Craig L Russell wrote: > Hi Kevin, > > I don't know if it's relevant, but persistent classes must not be > final. It seems that the entities in the model.company packages are > (all) final, which is wrong. From spec 2.1, "The entity class must > not be final. No methods or persistent instance variables of the > entity class may be final. " > > The relevant part of the stack trace appears to be: >> Caused by: java.lang.NoSuchMethodException: =Class.create >> (Class); >>at java.beans.Statement.invoke(Statement.java:269) >>at .(Unknown Source) >>at com.sun.beans.ObjectHandler.eval(ObjectHandler.java:148) >>at com.sun.beans.ObjectHandler.startElement >> (ObjectHandler.java:250) >>at org.apache.xerces.parsers.AbstractSAXParser.startElement >> (Unknown >> Source) >>at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement >> (Unknown > > which sounds like an issue with the xerces parser. Don't you hate > exceptions from parsers rather than error messages? > > Craig > > On Feb 10, 2007, at 8:08 PM, Kevin Sutter wrote: > >> Marc, >> It took a while to reproduce, but I finally got the following... >> Does this >> help? Thanks for your help! >> >> Kevin >> >> Running >> org.apache.openjpa.persistence.models.company.propertyaccess.TestProp >> ertyCompanyModel >> 0 test INFO [main] openjpa.Runtime - Starting OpenJPA 0.0.0 >> 0 test INFO [main] openjpa.jdbc.JDBC - OpenJPA will now >> connect to the >> database to attempt to determine what type of database dictionary >> to use. >> To prevent this connection in the future, set your >> openjpa.jdbc.DBDictionaryconfiguration property to the appropriate >> value for your database (see the >> documentation foravailable values). >> 0 test INFO [main] openjpa.jdbc.JDBC - Using dictionary class " >> org.apache.openjpa.jdbc.sql.DerbyDictionary" (Apache Derby 10.2.2.0 - >> (485682) ,Apache Derby >> Embedded JDBC Driver 10.2.2.0 - (485682)). >> 10 test INFO [main] openjpa.MetaData - Found 10 classes with >> metadata in >> 0 milliseconds. >> 20 test INFO [main] openjpa.MetaData - Found 10 classes with >> metadata in >> 10 milliseconds. >> 20 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.Product" >> . >> 20 test INFO [main] openjpa.MetaData - Parsing package " >> org.apache.openjpa.persistence.models.company.propertyaccess.Product" >> . >> 30 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.Company" >> . >> 30 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.Address" >> . >> 40 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.Employee >> ". >> 40 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.Person". >> 50 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.FullTime >> Employee >> ". >> 50 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.LineItem >> ". >> 60 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.ProductO >> rder". >> 60 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.Customer >> ". >> 70 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.PartTime >> Employee >> ". >> 70 test INFO [main] openjpa.jdbc.Schema - Reading table >> information for >> schema name "null", table name "PRP_Address". >> 80 test INFO [main] openjpa.jdbc.Schema - Reading table >> information for >> schema name "null", table name "PRP_Company". >> 80 test INFO [main] openjpa.jdbc.Schema - Reading table >> information for >> schema name "null", table name "PRP_LineItem". >> 80 test INFO [main] openjpa.jdbc.Schema - Reading table >> inf
[jira] Created: (OPENJPA-141) More performance improvements (in response to changes for OPENJPA-138)
More performance improvements (in response to changes for OPENJPA-138)
--
Key: OPENJPA-141
URL: https://issues.apache.org/jira/browse/OPENJPA-141
Project: OpenJPA
Issue Type: Sub-task
Components: jpa
Reporter: Kevin Sutter
Assigned To: Kevin Sutter
Abe's response to my committed changes for OPENJPA-138. I will be working with
Abe and my performance team to work through these issues...
> ==
>
> --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> openjpa/ee/JNDIManagedRuntime.java (original)
> +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> @@ -29,6 +29,7 @@
> implements ManagedRuntime {
>
> private String _tmLoc = "java:/TransactionManager";
> +private static TransactionManager _tm;
Whoa, I didn't think you meant caching the TM statically. That has
to be backed out. You can cache it in an instance variable, but not
statically. Nothing should prevent someone having two different
BrokerFactories accessing two different TMs at two different JNDI
locations.
BrokerImpl:
> + * Cache from/to assignments to avoid Class.isAssignableFrom
> overhead
> + * @param from the target Class
> + * @param to the Class to test
> + * @return true if the "to" class could be assigned to "from"
> class
> + */
> +private boolean isAssignable(Class from, Class to) {
> + boolean isAssignable;
> + ConcurrentReferenceHashMap assignableTo =
> + (ConcurrentReferenceHashMap) _assignableTypes.get(from);
> +
> + if (assignableTo != null) { // "to" cache exists...
> + isAssignable = (assignableTo.get(to) != null);
> + if (!isAssignable) { // not in the map yet...
> + isAssignable = from.isAssignableFrom(to);
> + if (isAssignable) {
> + assignableTo.put(to, new Object());
> + }
> + }
> + } else { // no "to" cache yet...
> + isAssignable = from.isAssignableFrom(to);
> + if (isAssignable) {
> + assignableTo = new ConcurrentReferenceHashMap(
> + ReferenceMap.HARD, ReferenceMap.WEAK);
> + _assignableTypes.put(from, assignableTo);
> + assignableTo.put(to, new Object());
> + }
> + }
> + return isAssignable;
> +}
This code could be simplified a lot. Also, I don't understand what
you're trying to do from a memory management perspective. For the
_assignableTypes member you've got the Class keys using hard refs and
the Map values using weak refs. No outside code references the Map
values, so all entries should be eligible for GC pretty much
immediately. The way reference hash maps work prevents them from
expunging stale entries except on mutators, but still... every time a
new entry is added, all the old entries should be getting GC'd and
removed. Same for the individual Map values, which again map a hard
class ref to an unreferenced object value with a weak ref. Basically
the whole map-of-maps system should never contain more than one entry
total after a GC run and a mutation.
I'd really like to see you run your tests under a different JVM,
because it seems to me like (a) this shouldn't be necessary in the
first place, and (b) if this is working, it's again only because of
some JVM particulars or GC timing particulars or testing particulars
(I've seen profilers skew results in random ways like this) or even a
bug in ConcurrentReferenceHashMap.
The same goes for all the repeat logic in FetchConfigurationImpl.
And if we keep this code or some variant of it, I strongly suggest
moving it to a common place like ImplHelper.
> +/**
> + * Generate the hashcode for this Id. Cache the type's
> generated hashcode
> + * so that it doesn't have to be generated each time.
> + */
> public int hashCode() {
> if (_typeHash == 0) {
> -Class base = type;
> -while (base.getSuperclass() != null
> -&& base.getSuperclass() != Object.class)
> -base = base.getSuperclass();
> -_typeHash = base.hashCode();
> +Integer typeHashInt = (Integer) _typeCache.get(type);
> +if (typeHashInt == null) {
> +Class base = type;
> +Class superclass = base.getSuperclass();
> +while (superclass != null && superclass !=
> Object.class) {
> +base = base.getSuperclass();
> +superclass = base.getSuperclass();
> +}
> +_typeHash = base.hashCode();
> +_typeCache.put(type, new Integer(_typeHash));
> +} else {
> +_typeHash = t
Re: svn commit: r506230 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/ee/ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ openjpa-kernel/src/main/java/org/apac
Thanks for the feedback. I know that we have been running with both the IBM and Sun JDK's, but let me get together with my performance team and discuss your concerns. We will try to provide more concrete data on these updates. Cool. Maybe I'll learn something about weak refs and the implementation of java.lang.Class from them, because right now I'm thoroughly confused about how those caches are helping. ___ 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.
Re: svn commit: r506230 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/ee/ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ openjpa-kernel/src/main/java/org/apac
I have created OPENJPA-141 (
https://issues.apache.org/jira/browse/OPENJPA-141) to track these issues.
Kevin
On 2/12/07, Abe White <[EMAIL PROTECTED]> wrote:
> ==
>
> --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> openjpa/ee/JNDIManagedRuntime.java (original)
> +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> @@ -29,6 +29,7 @@
> implements ManagedRuntime {
>
> private String _tmLoc = "java:/TransactionManager";
> +private static TransactionManager _tm;
Whoa, I didn't think you meant caching the TM statically. That has
to be backed out. You can cache it in an instance variable, but not
statically. Nothing should prevent someone having two different
BrokerFactories accessing two different TMs at two different JNDI
locations.
BrokerImpl:
> + * Cache from/to assignments to avoid Class.isAssignableFrom
> overhead
> + * @param from the target Class
> + * @param to the Class to test
> + * @return true if the "to" class could be assigned to "from"
> class
> + */
> +private boolean isAssignable(Class from, Class to) {
> + boolean isAssignable;
> + ConcurrentReferenceHashMap assignableTo =
> + (ConcurrentReferenceHashMap) _assignableTypes.get(from);
> +
> + if (assignableTo != null) { // "to" cache exists...
> + isAssignable = (assignableTo.get(to) != null);
> + if (!isAssignable) { // not in the map yet...
> + isAssignable = from.isAssignableFrom(to);
> + if (isAssignable) {
> + assignableTo.put(to, new Object());
> + }
> + }
> + } else { // no "to" cache yet...
> + isAssignable = from.isAssignableFrom(to);
> + if (isAssignable) {
> + assignableTo = new ConcurrentReferenceHashMap(
> + ReferenceMap.HARD, ReferenceMap.WEAK);
> + _assignableTypes.put(from, assignableTo);
> + assignableTo.put(to, new Object());
> + }
> + }
> + return isAssignable;
> +}
This code could be simplified a lot. Also, I don't understand what
you're trying to do from a memory management perspective. For the
_assignableTypes member you've got the Class keys using hard refs and
the Map values using weak refs. No outside code references the Map
values, so all entries should be eligible for GC pretty much
immediately. The way reference hash maps work prevents them from
expunging stale entries except on mutators, but still... every time a
new entry is added, all the old entries should be getting GC'd and
removed. Same for the individual Map values, which again map a hard
class ref to an unreferenced object value with a weak ref. Basically
the whole map-of-maps system should never contain more than one entry
total after a GC run and a mutation.
I'd really like to see you run your tests under a different JVM,
because it seems to me like (a) this shouldn't be necessary in the
first place, and (b) if this is working, it's again only because of
some JVM particulars or GC timing particulars or testing particulars
(I've seen profilers skew results in random ways like this) or even a
bug in ConcurrentReferenceHashMap.
The same goes for all the repeat logic in FetchConfigurationImpl.
And if we keep this code or some variant of it, I strongly suggest
moving it to a common place like ImplHelper.
> +/**
> + * Generate the hashcode for this Id. Cache the type's
> generated hashcode
> + * so that it doesn't have to be generated each time.
> + */
> public int hashCode() {
> if (_typeHash == 0) {
> -Class base = type;
> -while (base.getSuperclass() != null
> -&& base.getSuperclass() != Object.class)
> -base = base.getSuperclass();
> -_typeHash = base.hashCode();
> +Integer typeHashInt = (Integer) _typeCache.get(type);
> +if (typeHashInt == null) {
> +Class base = type;
> +Class superclass = base.getSuperclass();
> +while (superclass != null && superclass !=
> Object.class) {
> +base = base.getSuperclass();
> +superclass = base.getSuperclass();
> +}
> +_typeHash = base.hashCode();
> +_typeCache.put(type, new Integer(_typeHash));
> +} else {
> +_typeHash = typeHashInt.intValue();
> +}
> }
> return _typeHash ^ idHash();
> }
Once again, you're mapping a hard Class ref to a value with no
outside references held in a weak ref. Once again that means the
entry should be immediately eligible for GC, and therefore should be
removed on the next mutation of the cache, subject to GC timing. And
again I'd like
Re: svn commit: r506230 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/ee/ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ openjpa-kernel/src/main/java/org/apac
Abe,
Thanks for the feedback. I know that we have been running with both the IBM
and Sun JDK's, but let me get together with my performance team and discuss
your concerns. We will try to provide more concrete data on these updates.
I understand your concerns, but instead of immediately backing out these
changes (since none of our existing test buckets or other testing is
directly affected), I'll just open another JIRA Issue to resolve these
issues in short order. Thanks for your patience.
Kevin
On 2/12/07, Abe White <[EMAIL PROTECTED]> wrote:
> ==
>
> --- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> openjpa/ee/JNDIManagedRuntime.java (original)
> +++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
> openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
> @@ -29,6 +29,7 @@
> implements ManagedRuntime {
>
> private String _tmLoc = "java:/TransactionManager";
> +private static TransactionManager _tm;
Whoa, I didn't think you meant caching the TM statically. That has
to be backed out. You can cache it in an instance variable, but not
statically. Nothing should prevent someone having two different
BrokerFactories accessing two different TMs at two different JNDI
locations.
BrokerImpl:
> + * Cache from/to assignments to avoid Class.isAssignableFrom
> overhead
> + * @param from the target Class
> + * @param to the Class to test
> + * @return true if the "to" class could be assigned to "from"
> class
> + */
> +private boolean isAssignable(Class from, Class to) {
> + boolean isAssignable;
> + ConcurrentReferenceHashMap assignableTo =
> + (ConcurrentReferenceHashMap) _assignableTypes.get(from);
> +
> + if (assignableTo != null) { // "to" cache exists...
> + isAssignable = (assignableTo.get(to) != null);
> + if (!isAssignable) { // not in the map yet...
> + isAssignable = from.isAssignableFrom(to);
> + if (isAssignable) {
> + assignableTo.put(to, new Object());
> + }
> + }
> + } else { // no "to" cache yet...
> + isAssignable = from.isAssignableFrom(to);
> + if (isAssignable) {
> + assignableTo = new ConcurrentReferenceHashMap(
> + ReferenceMap.HARD, ReferenceMap.WEAK);
> + _assignableTypes.put(from, assignableTo);
> + assignableTo.put(to, new Object());
> + }
> + }
> + return isAssignable;
> +}
This code could be simplified a lot. Also, I don't understand what
you're trying to do from a memory management perspective. For the
_assignableTypes member you've got the Class keys using hard refs and
the Map values using weak refs. No outside code references the Map
values, so all entries should be eligible for GC pretty much
immediately. The way reference hash maps work prevents them from
expunging stale entries except on mutators, but still... every time a
new entry is added, all the old entries should be getting GC'd and
removed. Same for the individual Map values, which again map a hard
class ref to an unreferenced object value with a weak ref. Basically
the whole map-of-maps system should never contain more than one entry
total after a GC run and a mutation.
I'd really like to see you run your tests under a different JVM,
because it seems to me like (a) this shouldn't be necessary in the
first place, and (b) if this is working, it's again only because of
some JVM particulars or GC timing particulars or testing particulars
(I've seen profilers skew results in random ways like this) or even a
bug in ConcurrentReferenceHashMap.
The same goes for all the repeat logic in FetchConfigurationImpl.
And if we keep this code or some variant of it, I strongly suggest
moving it to a common place like ImplHelper.
> +/**
> + * Generate the hashcode for this Id. Cache the type's
> generated hashcode
> + * so that it doesn't have to be generated each time.
> + */
> public int hashCode() {
> if (_typeHash == 0) {
> -Class base = type;
> -while (base.getSuperclass() != null
> -&& base.getSuperclass() != Object.class)
> -base = base.getSuperclass();
> -_typeHash = base.hashCode();
> +Integer typeHashInt = (Integer) _typeCache.get(type);
> +if (typeHashInt == null) {
> +Class base = type;
> +Class superclass = base.getSuperclass();
> +while (superclass != null && superclass !=
> Object.class) {
> +base = base.getSuperclass();
> +superclass = base.getSuperclass();
> +}
> +_typeHash = base.hashCode();
> +_typeCache.put(type, new Integer(_typeHash));
> +} else {
> +_typ
Re: svn commit: r506230 - in /incubator/openjpa/trunk: openjpa-kernel/src/main/java/org/apache/openjpa/ee/ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ openjpa-kernel/src/main/java/org/apac
==
--- incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
openjpa/ee/JNDIManagedRuntime.java (original)
+++ incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/
openjpa/ee/JNDIManagedRuntime.java Sun Feb 11 18:33:05 2007
@@ -29,6 +29,7 @@
implements ManagedRuntime {
private String _tmLoc = "java:/TransactionManager";
+private static TransactionManager _tm;
Whoa, I didn't think you meant caching the TM statically. That has
to be backed out. You can cache it in an instance variable, but not
statically. Nothing should prevent someone having two different
BrokerFactories accessing two different TMs at two different JNDI
locations.
BrokerImpl:
+ * Cache from/to assignments to avoid Class.isAssignableFrom
overhead
+ * @param from the target Class
+ * @param to the Class to test
+ * @return true if the "to" class could be assigned to "from"
class
+ */
+private boolean isAssignable(Class from, Class to) {
+ boolean isAssignable;
+ ConcurrentReferenceHashMap assignableTo =
+ (ConcurrentReferenceHashMap) _assignableTypes.get(from);
+
+ if (assignableTo != null) { // "to" cache exists...
+ isAssignable = (assignableTo.get(to) != null);
+ if (!isAssignable) { // not in the map yet...
+ isAssignable = from.isAssignableFrom(to);
+ if (isAssignable) {
+ assignableTo.put(to, new Object());
+ }
+ }
+ } else { // no "to" cache yet...
+ isAssignable = from.isAssignableFrom(to);
+ if (isAssignable) {
+ assignableTo = new ConcurrentReferenceHashMap(
+ ReferenceMap.HARD, ReferenceMap.WEAK);
+ _assignableTypes.put(from, assignableTo);
+ assignableTo.put(to, new Object());
+ }
+ }
+ return isAssignable;
+}
This code could be simplified a lot. Also, I don't understand what
you're trying to do from a memory management perspective. For the
_assignableTypes member you've got the Class keys using hard refs and
the Map values using weak refs. No outside code references the Map
values, so all entries should be eligible for GC pretty much
immediately. The way reference hash maps work prevents them from
expunging stale entries except on mutators, but still... every time a
new entry is added, all the old entries should be getting GC'd and
removed. Same for the individual Map values, which again map a hard
class ref to an unreferenced object value with a weak ref. Basically
the whole map-of-maps system should never contain more than one entry
total after a GC run and a mutation.
I'd really like to see you run your tests under a different JVM,
because it seems to me like (a) this shouldn't be necessary in the
first place, and (b) if this is working, it's again only because of
some JVM particulars or GC timing particulars or testing particulars
(I've seen profilers skew results in random ways like this) or even a
bug in ConcurrentReferenceHashMap.
The same goes for all the repeat logic in FetchConfigurationImpl.
And if we keep this code or some variant of it, I strongly suggest
moving it to a common place like ImplHelper.
+/**
+ * Generate the hashcode for this Id. Cache the type's
generated hashcode
+ * so that it doesn't have to be generated each time.
+ */
public int hashCode() {
if (_typeHash == 0) {
-Class base = type;
-while (base.getSuperclass() != null
-&& base.getSuperclass() != Object.class)
-base = base.getSuperclass();
-_typeHash = base.hashCode();
+Integer typeHashInt = (Integer) _typeCache.get(type);
+if (typeHashInt == null) {
+Class base = type;
+Class superclass = base.getSuperclass();
+while (superclass != null && superclass !=
Object.class) {
+base = base.getSuperclass();
+superclass = base.getSuperclass();
+}
+_typeHash = base.hashCode();
+_typeCache.put(type, new Integer(_typeHash));
+} else {
+_typeHash = typeHashInt.intValue();
+}
}
return _typeHash ^ idHash();
}
Once again, you're mapping a hard Class ref to a value with no
outside references held in a weak ref. Once again that means the
entry should be immediately eligible for GC, and therefore should be
removed on the next mutation of the cache, subject to GC timing. And
again I'd like to know what your JVM is doing to make Class.hashCode
take an appreciable amount of time. Aren't Class instances supposed
to be singletons? What if we just used System.identityHashCode(cls)?
Modified: incubator/openjpa
WG: Using @GeneratedValue for IDs on already existing tables
-Ursprüngliche Nachricht- Von: Hans J. Prueller [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 10. Februar 2007 18:24 An: open-jpa-dev@incubator.apache.org Betreff: Using @GeneratedValue for IDs on already existing tables As some of you may remember, I am using OpenJPA within an "old" Java2EE 1.4/EJB2.1 container to perform a step-by-step or bean-by-bean migration from our EJB2.1 CMP entity beans to new EJB3 Beans with JPA. For the IDs of the Entity Beans we have been using a Container-Generated-Value and I plan to continue doing so by using the JPA's @GeneratedValue stuff. Are there any special issues to consider when using the new openJPA based entities with generated values on already existing data? In special I mean conflicts of between openJPA generated IDs with existing IDs in the underlying table? Hans
Re: Strange, intermittent problem running the new models.company tests
Marc (and others), Shouldn't OpenJPA be detecting these final classes and issuing an error message? Kevin On 2/12/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: Craig- You're right that the classes shouldn't be final, but I don't think that's the cause of the problem. I've committed a fix to the final class issue, though. Thanks for pointing it out. On Feb 10, 2007, at 10:07 PM, Craig L Russell wrote: > Hi Kevin, > > I don't know if it's relevant, but persistent classes must not be > final. It seems that the entities in the model.company packages are > (all) final, which is wrong. From spec 2.1, "The entity class must > not be final. No methods or persistent instance variables of the > entity class may be final. " > > The relevant part of the stack trace appears to be: >> Caused by: java.lang.NoSuchMethodException: =Class.create >> (Class); >>at java.beans.Statement.invoke(Statement.java:269) >>at .(Unknown Source) >>at com.sun.beans.ObjectHandler.eval(ObjectHandler.java:148) >>at com.sun.beans.ObjectHandler.startElement >> (ObjectHandler.java:250) >>at org.apache.xerces.parsers.AbstractSAXParser.startElement >> (Unknown >> Source) >>at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement >> (Unknown > > which sounds like an issue with the xerces parser. Don't you hate > exceptions from parsers rather than error messages? > > Craig > > On Feb 10, 2007, at 8:08 PM, Kevin Sutter wrote: > >> Marc, >> It took a while to reproduce, but I finally got the following... >> Does this >> help? Thanks for your help! >> >> Kevin >> >> Running >> org.apache.openjpa.persistence.models.company.propertyaccess.TestProp >> ertyCompanyModel >> 0 test INFO [main] openjpa.Runtime - Starting OpenJPA 0.0.0 >> 0 test INFO [main] openjpa.jdbc.JDBC - OpenJPA will now >> connect to the >> database to attempt to determine what type of database dictionary >> to use. >> To prevent this connection in the future, set your >> openjpa.jdbc.DBDictionaryconfiguration property to the appropriate >> value for your database (see the >> documentation foravailable values). >> 0 test INFO [main] openjpa.jdbc.JDBC - Using dictionary class " >> org.apache.openjpa.jdbc.sql.DerbyDictionary" (Apache Derby 10.2.2.0 - >> (485682) ,Apache Derby >> Embedded JDBC Driver 10.2.2.0 - (485682)). >> 10 test INFO [main] openjpa.MetaData - Found 10 classes with >> metadata in >> 0 milliseconds. >> 20 test INFO [main] openjpa.MetaData - Found 10 classes with >> metadata in >> 10 milliseconds. >> 20 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.Product" >> . >> 20 test INFO [main] openjpa.MetaData - Parsing package " >> org.apache.openjpa.persistence.models.company.propertyaccess.Product" >> . >> 30 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.Company" >> . >> 30 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.Address" >> . >> 40 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.Employee >> ". >> 40 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.Person". >> 50 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.FullTime >> Employee >> ". >> 50 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.LineItem >> ". >> 60 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.ProductO >> rder". >> 60 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.Customer >> ". >> 70 test INFO [main] openjpa.MetaData - Parsing class " >> org.apache.openjpa.persistence.models.company.propertyaccess.PartTime >> Employee >> ". >> 70 test INFO [main] openjpa.jdbc.Schema - Reading table >> information for >> schema name "null", table name "PRP_Address". >> 80 test INFO [main] openjpa.jdbc.Schema - Reading table >> information for >> schema name "null", table name "PRP_Company". >> 80 test INFO [main] openjpa.jdbc.Schema - Reading table >> information for >> schema name "null", table name "PRP_LineItem". >> 80 test INFO [main] openjpa.jdbc.Schema - Reading table >> information for >> schema name "null", table name "PRP_Person". >> 80 test INFO [main] openjpa.jdbc.Schema - Reading table >> information for >> schema name "null", table name "PRP_Product". >> 110 test INFO [main] openjpa.jdbc.Schema - Reading table >> information for >> schema name "null", table name "PRP_ProductOrder". >> 120 test INFO [main] openjpa.jdbc.Schema - Reading table >> inform
Vlad Tatavu is out of the office.
I will be out of the office starting 12/02/2007 and will not return until 16/02/2007. I will respond to your message when I return.
