[jira] Commented: (OPENJPA-242) JCache (JSR 107) support in the OpenJPA DataCache
[ https://issues.apache.org/jira/browse/OPENJPA-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498741 ] Craig Russell commented on OPENJPA-242: --- I'd like to see OpenJPA support a variety of caching implementations, but it's not clear that JSR 107 is the right approach. According to http://jcp.org/en/jsr/detail?id=107 the last activity on this JSR was in 2001. So there really isn't yet a JSR 107 compliant standard. Is there any other product in addition to EHCache that supports a more common interface? JCache (JSR 107) support in the OpenJPA DataCache - Key: OPENJPA-242 URL: https://issues.apache.org/jira/browse/OPENJPA-242 Project: OpenJPA Issue Type: New Feature Components: datacache Affects Versions: 0.9.0, 0.9.6, 0.9.7 Reporter: Marc Prud'hommeaux Priority: Minor JSR 107 (JCache: http://jcp.org/en/jsr/detail?id=107 ) support would enable OpenJPA to integrate its data cache with supporting products in a transparent way. This would allow us to support the popular EHCache 1.3 and other JSR 107 compliant caching layers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-233) Top level POM declares a compile-time dependency on JUnit
[ https://issues.apache.org/jira/browse/OPENJPA-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Russell resolved OPENJPA-233. --- Resolution: Fixed Assignee: Craig Russell checked in patch. Top level POM declares a compile-time dependency on JUnit - Key: OPENJPA-233 URL: https://issues.apache.org/jira/browse/OPENJPA-233 Project: OpenJPA Issue Type: Bug Components: build / infrastructure Affects Versions: 0.9.7 Reporter: Craig Russell Assigned To: Craig Russell Priority: Trivial Fix For: 0.9.8 trunk/pom.xml declares the following maven dependency on JUnit. dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopecompile/scope /dependency The dependency should be test, not compile, as required only by test components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-194) Correct suffixes of build artifacts to elimiate '-all' and '-project'
[ https://issues.apache.org/jira/browse/OPENJPA-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493954 ] Craig Russell commented on OPENJPA-194: --- I like the direction, just have a couple of questions. The patch changes the parent from openjpa to openjpa-parent. From your description, this doesn't really affect anything else (except for freeing up the openjpa name for another purpose. Nice change to use the scm.dir location in other poms. This is the variable that we'll have to change once we graduate. While we're at is, is there any way to do the same refactoring to urlhttp://incubator.apache.org/projects/openjpa/url which appears in lots of places? Patch that changes artifact names so that the openjpa aggregate jar is named openjpa-VERSION.jar, So this changes openjpa-all-VERSION.jar to openjpa-VERSION.jar. This is great. the dependency is named openjpa, I think you are talking about the artifactId in the dependency section of projects that use OpenJPA. If so, great. and the assembly is named apache-openjpa-VERSION.zip. So that's the non-maven artifact. Aren't there binary and source versions of this artifact? And .zip and .tar.gz versions of those? The name is pretty arbitrary, and while I don't like openjpa-project, I don't really like apache-openjpa either, because it doesn't imply a bundle or distribution. How about openjpa-distribution or openjpa-bundle? Or simply openjpa-src-0.9.7.zip and openjpa-binary-0.9.7.zip? I guess that would imply a different maven project for the source and binary distributions... Correct suffixes of build artifacts to elimiate '-all' and '-project' - Key: OPENJPA-194 URL: https://issues.apache.org/jira/browse/OPENJPA-194 Project: OpenJPA Issue Type: Sub-task Components: build / infrastructure Affects Versions: 0.9.0, 0.9.6 Reporter: Marc Prud'hommeaux Assigned To: Marc Prud'hommeaux Priority: Minor Fix For: 0.9.8 Attachments: OpenJPA-194-1.patch.txt, OPENJPA-194.patch The aggregate jar that is built with OpenJPA is currently named openjpa-all-0.9.7-VERSION.jar. It would be nice to change this to be just openjpa-0.9.7-VERSION.jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-148) Parsing exception while using an exploded archive
[ https://issues.apache.org/jira/browse/OPENJPA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493736 ] Craig Russell commented on OPENJPA-148: --- Just thinking a bit outside the box here. Is it possibly a bug that the classes directory is being presented as a file? And perhaps defensively OpenJPA might check to see if the file is actually a directory and then just ignore it. i.e. if (file.isDirectory()) continue; But I'd like to see a bit more investigation into whether the behavior of the container is correct. It does seem odd that the container is expecting the provider to remove duplicate items from the deployment artifact. Parsing exception while using an exploded archive --- Key: OPENJPA-148 URL: https://issues.apache.org/jira/browse/OPENJPA-148 Project: OpenJPA Issue Type: Bug Components: jpa Environment: Sun JDK 5.0 / EasyBeans / OpenJPA snapshot 0.9.7 Reporter: Florent BENOIT Priority: Minor Fix For: 0.9.8 Attachments: debug_traces_directorymode.txt, debug_traces_filemode_working.txt, OPENJPA-148.patch, stacktrace-error.txt, steps.txt This happens when using OpenJPA as persistence provider for the EasyBeans ObjectWeb container. The error is happening with exploded archive. Exploded means that there is a directory, named entitybean.jar with a folder META-INF which contains a file named persistence.xml, and other directories/files for the classes. It seems that when using this mode, OpenJPA is trying to parse the directory inputstream (which is failing). This exception is not occuring if a jar file is used instead of the exploded mode, but the exploded mode is the default mode for EasyBeans. Note also that this exception don't occur by using Hibernate Entity Manager or Oracle TopLink Essentials as persistence provider. I will attach to this issue a stack trace (with the exploded directory) which fails and at the end with a jar file (which work) And 4 steps used to reproduce this problem -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-233) Top level POM declares a compile-time dependency on JUnit
Top level POM declares a compile-time dependency on JUnit - Key: OPENJPA-233 URL: https://issues.apache.org/jira/browse/OPENJPA-233 Project: OpenJPA Issue Type: Bug Components: build / infrastructure Affects Versions: 0.9.7 Reporter: Craig Russell Priority: Trivial Fix For: 0.9.8 trunk/pom.xml declares the following maven dependency on JUnit. dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopecompile/scope /dependency The dependency should be test, not compile, as required only by test components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-233) Top level POM declares a compile-time dependency on JUnit
[ https://issues.apache.org/jira/browse/OPENJPA-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493116 ] Craig Russell commented on OPENJPA-233: --- This patch changes the dependency from compile to test. Index: pom.xml === --- pom.xml (revision 534391) +++ pom.xml (working copy) @@ -220,7 +220,7 @@ groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version -scopecompile/scope +scopetest/scope /dependency /dependencies build Top level POM declares a compile-time dependency on JUnit - Key: OPENJPA-233 URL: https://issues.apache.org/jira/browse/OPENJPA-233 Project: OpenJPA Issue Type: Bug Components: build / infrastructure Affects Versions: 0.9.7 Reporter: Craig Russell Priority: Trivial Fix For: 0.9.8 trunk/pom.xml declares the following maven dependency on JUnit. dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopecompile/scope /dependency The dependency should be test, not compile, as required only by test components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-233) Top level POM declares a compile-time dependency on JUnit
[ https://issues.apache.org/jira/browse/OPENJPA-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493122 ] Craig Russell commented on OPENJPA-233: --- Why not move on up to the 4.1 junit suite as well while we are at it. Backwards compatible and more robust? I guess because I believe in making one change at a time. I'm not sure I have the complete test infrastructure to make sure that a new version of JUnit would work. There are several test suites outside of the project that might be affected. Top level POM declares a compile-time dependency on JUnit - Key: OPENJPA-233 URL: https://issues.apache.org/jira/browse/OPENJPA-233 Project: OpenJPA Issue Type: Bug Components: build / infrastructure Affects Versions: 0.9.7 Reporter: Craig Russell Priority: Trivial Fix For: 0.9.8 trunk/pom.xml declares the following maven dependency on JUnit. dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopecompile/scope /dependency The dependency should be test, not compile, as required only by test components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
[ https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487082 ] Craig Russell commented on OPENJPA-182: --- I know that Oracle allows you to add a FOR UPDATE clause to a query, and this affects the results of that query. In Sun appserver CMP we use this to set exclusive locks on rows where we want pessimistic locking behavior just for certain tables. db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS -- Key: OPENJPA-182 URL: https://issues.apache.org/jira/browse/OPENJPA-182 Project: OpenJPA Issue Type: New Feature Components: jdbc Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux Reporter: David Wisneski Assigned To: David Wisneski Attachments: OPENJPA-182.patch, openJPA182.patch A while back we changed the syntax of update locking from FOR UPDATE OF to WITH RS USE AND KEEP UPDATE LOCKS. Additional changes are required because 1. if isolation=serializable is configured, then the syntax should be WITH RR USE AND KEEP UDPATE LOCKS 2. when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND KEEP EXCLUSIVE LOCKS or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 only supports read or exclusive locks. 3. DB2 supports both a FETCH FIRST ROWS and update LOCKS clauses. So we change supportsLockingWithSelectRange = true in the AbstractDB2Dictionary class and change the DB2Dictionary to append the correct LOCKS syntax depending on vendor, release and isolation level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-182) db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS
[ https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486812 ] Craig Russell commented on OPENJPA-182: --- A use-case for the isolation level is to support different locking semantics for different classes and possibly for different queries. To use Patrick's patch would I need to use a different fetch plan before issuing a find or a query and then set it back after that method call? Or can I specify an isolation level in the FetchConfiguration per class? db2 update lock syntax WITH isolation USE AND KEEP UPDATE LOCKS -- Key: OPENJPA-182 URL: https://issues.apache.org/jira/browse/OPENJPA-182 Project: OpenJPA Issue Type: New Feature Components: jdbc Environment: db2 database driver for zOS, AS400, Unix, Windows, Linux Reporter: David Wisneski Assigned To: David Wisneski Attachments: OPENJPA-182.patch, openJPA182.patch A while back we changed the syntax of update locking from FOR UPDATE OF to WITH RS USE AND KEEP UPDATE LOCKS. Additional changes are required because 1. if isolation=serializable is configured, then the syntax should be WITH RR USE AND KEEP UDPATE LOCKS 2. when using DB2/400 on iSeries machines, the syntax is WITH RS USE AND KEEP EXCLUSIVE LOCKS or WITH RR USE AND KEEP EXCLUSIVE LOCKS because DB2/400 only supports read or exclusive locks. 3. DB2 supports both a FETCH FIRST ROWS and update LOCKS clauses. So we change supportsLockingWithSelectRange = true in the AbstractDB2Dictionary class and change the DB2Dictionary to append the correct LOCKS syntax depending on vendor, release and isolation level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-20) Query can return embeddable class
[ https://issues.apache.org/jira/browse/OPENJPA-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477043 ] Craig Russell commented on OPENJPA-20: -- I agree with Marc that it's a bug in the doc. The doc could also be reworded like Embedded classes cannot be used as the first entity in the FROM clause of a query. They can only be returned by projecting from an entity that embeds them. Query can return embeddable class - Key: OPENJPA-20 URL: https://issues.apache.org/jira/browse/OPENJPA-20 Project: OpenJPA Issue Type: Bug Components: docs Reporter: David Wisneski Priority: Minor part 2 , chapter 4 of user manual on Entity, states that embeddable classes are never returned from a query. This is not true as in the query select e.address from EmpBean e address could be defined as as embeddable class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476731 ] Craig Russell commented on OPENJPA-160: --- K... IMO, we should get rid of the finalizer in the default config, and create a new FinalizingBrokerImpl that has a finalizer, that can optionally be used by developers. I think that we should make that the default, and then let appserver providers (who are the most likely to definitely control resources correctly) turn the finalization off. Two comments, one procedural. 1. I really think we're going just a bit too fast here. I wasn't able to comment on the discussion because I've been in meetings all morning, and it's really tough to find the issue resolved, a patch committed, and I never had a chance. I also notice that just minutes after the commit, Abe had a comment that resulted in another change. For issues that attract this kind of attention, I think a little more time is probably needed to reach closure. 2. I'd like to reopen the discussion of which BrokerImpl should be the default. In general, I like performance options to be the default. It makes the out of the box experience better because users don't need to find, much less read, the relevant part of the documentation. Well-behaved applications don't need the finalizer. Small applications running in short-lived vms don't need it. So it seems the finalizer is only really needed in long-lived vms (application servers, web servers) that have poorly designed applications. Why is this the default? Applications that don't close their ems should be slapped about the upper body. Seems that the finalize method should do some strenuous logging (WARNING or SEVERE) to point out to the developer that they need to change their ways. Bottom line, I guess I'd prefer that the finalizer version be documented in the troubleshooting section of the doc. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Assigned To: Patrick Linskey Attachments: newprofile.jpg, openjpa-160-clone-patch.txt, openjpa-160-finalization-and-cloning-patch.txt, openjpa-160-patch.txt, openjpa-160-patch.txt, openjpa-160-patch.txt, openjpa-160-patch.txt, perf2.jpg, perf3.jpg, profile_clonepatch.jpg, profile_explicitclass.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-35) In-memory Delete operation fails with active DataCache
[ https://issues.apache.org/jira/browse/OPENJPA-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476808 ] Craig Russell commented on OPENJPA-35: -- I agree this bug is worth fixing and pending the fix, worth documenting as a bug. I'd be against documenting it as a feature. In-memory Delete operation fails with active DataCache -- Key: OPENJPA-35 URL: https://issues.apache.org/jira/browse/OPENJPA-35 Project: OpenJPA Issue Type: Bug Components: datacache, query Affects Versions: 0.9.0, 0.9.6 Environment: Only happens when DataCache is active property name=openjpa.DataCache value=true/ property name=openjpa.RemoteCommitProvider value=sjvm/ Reporter: Pinaki Poddar Priority: Critical Fix For: 0.9.7 Attachments: openjpa-35.test.zip, openjpa-35.trace.txt Delete through query such as Query query = em.createQuery(DELETE FROM Node n); query.executeUpdate(); fails with following exception (only when DataCache is active) Exception in thread main 4|false|0.0.0 org.apache.openjpa.persistence.ArgumentException: org.apache.openjpa.datacache.QueryCacheStoreQuery at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1029) at org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeDelete(ExpressionStoreQuery.java:665) at org.apache.openjpa.datacache.QueryCacheStoreQuery$QueryCacheExecutor.executeDelete(QueryCacheStoreQuery.java:348) at org.apache.openjpa.kernel.QueryImpl.delete(QueryImpl.java:1012) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:768) at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:831) at org.apache.openjpa.kernel.QueryImpl.deleteAll(QueryImpl.java:827) at org.apache.openjpa.kernel.DelegatingQuery.deleteAll(DelegatingQuery.java:544) at org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:299) at control.Test.clear(Test.java:87) at control.Test.run(Test.java:37) at control.Test.main(Test.java:178) Caused by: java.lang.ClassCastException: org.apache.openjpa.datacache.QueryCacheStoreQuery at org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:651) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:949) at org.apache.openjpa.kernel.QueryImpl.deleteInMemory(QueryImpl.java:1018) ... 11 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476219 ] Craig Russell commented on OPENJPA-160: --- Sweet. The ObjectValue.InstanceFactory is the technique I was going to propose. My only question is whether this pattern exists anywhere else or only in ObjectValue. That might argue for making InstanceFactory a more general interface instead of being a member of ObjectValue. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Attachments: openjpa-160-patch.txt, perf2.jpg, perf3.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476225 ] Craig Russell commented on OPENJPA-160: --- As you've coded it, each instance of ObjectValue gets its own Map. Does a given instance need more than one factory? It could just be stored as a member instead of a Map. On the other hand, if the Map is static, it should probably be a Concurrent Map and account for garbage collecting undeployed classes. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Attachments: openjpa-160-patch.txt, perf2.jpg, perf3.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476295 ] Craig Russell commented on OPENJPA-160: --- I put a Map in place to get around any ClassLoader issues. In the common case, it shouldn't be an issue, since all the built-in OpenJPA classes will presumably be in the same classloader as the ObjectValue class. But the existing code handled more complex ClassLoader situations, so I figured I'd preserve that feature. Once you have a Class for the type, there are no classloader issues any more. The code only looks at the classloader of the type. So I don't see the need for generalization. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Attachments: openjpa-160-patch.txt, perf2.jpg, perf3.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Russell reassigned OPENJPA-160: - Assignee: Patrick Linskey Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Assigned To: Patrick Linskey Attachments: openjpa-160-patch.txt, openjpa-160-patch.txt, perf2.jpg, perf3.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476321 ] Craig Russell commented on OPENJPA-160: --- For the record, the new patch changes a couple of things. The factory method now does not take an argument, but what is registered is the full class name of the implementing class along with the factory for the class. This allows, for example, multiple factories to be registered for the same instance of ObjectValue, one of which is selected at configuration time. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Assigned To: Patrick Linskey Attachments: newprofile.jpg, openjpa-160-patch.txt, openjpa-160-patch.txt, perf2.jpg, perf3.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Russell updated OPENJPA-160: -- Attachment: openjpa-160-patch.txt This patch uses a regular class instead of an anonymous inner class to create the BrokerImplFactory. It is supposed to include everything in Patrick's patch. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Assigned To: Patrick Linskey Attachments: newprofile.jpg, openjpa-160-patch.txt, openjpa-160-patch.txt, openjpa-160-patch.txt, openjpa-160-patch.txt, perf2.jpg, perf3.jpg, profile_explicitclass.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476470 ] Craig Russell commented on OPENJPA-160: --- A few questions and a comment. 1. Is the profiling capturing CPU time or wait time? 2. Is the VM synchronizing on the constructor, possibly because of the finalize() method that needs to register with a collection? The VM might just synchronize before construction to avoid synchronizing later. 3. Do we really need the finalizer? 4. What about Patrick's suggestion to use clone() instead of constructing a new instance? Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Assigned To: Patrick Linskey Attachments: newprofile.jpg, openjpa-160-patch.txt, openjpa-160-patch.txt, openjpa-160-patch.txt, openjpa-160-patch.txt, perf2.jpg, perf3.jpg, profile_explicitclass.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475507 ] Craig Russell commented on OPENJPA-160: --- We ran some more performance tests with the latest OpenJPA code and the issue appears to be with creating an instance of the BrokerImpl (when Configurations calls Class.newInstance). I'm surprised that the time is being taken in the constructor. The BrokerImpl is actually initialized for real during the initialize method, not the constructor, and that's where I'd expect to find the initialization cost. There is no constructor implemented for BrokerImpl, so the only initialization done during the compiler-generated constructor is the initialization of the fields. Most of the fields are initialized to null, which takes no time (the initial memory allocated is cleared via a system clear memory call). The only things I see in the field initialization during newInstance are: private final JCAHelper _jca = new JCAHelper(); This is a stateless instance for which the constructor should be free. private ClassLoader _loader = Thread.currentThread(). getContextClassLoader(); Ah, perhaps this is the culprit? Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-160) Reuse BrokerImpl objects
[ https://issues.apache.org/jira/browse/OPENJPA-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475511 ] Craig Russell commented on OPENJPA-160: --- Great screen shot, but when I click on the frypan next to newInstance, nothing happens. ;-) Could you go a few levels down into newInstance and see what the heck is taking so long? My money is on getContextClassLoader or registerFinalizer. Reuse BrokerImpl objects Key: OPENJPA-160 URL: https://issues.apache.org/jira/browse/OPENJPA-160 Project: OpenJPA Issue Type: Sub-task Reporter: Michael Dick Attachments: perf2.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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_12473527
]
Craig Russell commented on OPENJPA-141:
---
Just posted another version of the performance patch for openjpa-141. I
believe I have honored the comments as posted to this Issue. Please take a
look and let's see if we can put this one to bed...
Looks good.
I have more performance-related items to pursue... :-)
I was hoping you did.
Thanks!
Thanks for your patience.
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
Attachments: openjpa-141.txt, openjpa-141.txt
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();
[jira] Commented: (OPENJPA-147) T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface
[ https://issues.apache.org/jira/browse/OPENJPA-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473536 ] Craig Russell commented on OPENJPA-147: --- Could you please attach the java definition of test.IPerson and the contents of META-INF/orm.xml to this issue? T T OpenJPAEntityManager.createInstance(ClassT cls) fails when T is interface - Key: OPENJPA-147 URL: https://issues.apache.org/jira/browse/OPENJPA-147 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Pinaki Poddar Attachments: iface.trace.1.txt, iface.trace.2.txt, iface.trace.3.txt, iface.trace.4.txt, TestInterface.java According to JavaDoc, OpenJPAEntityManager.createInstance() method public T T createInstance(ClassT cls); behaves as follows: Create a new instance of type codecls/code. If codecls/code is an interface or an abstract class whose abstract methods follow the JavaBeans convention, this method will create a concrete implementation according to the metadata that defines the class The method fails when T is an interface. The failure may be due to incorrect user configuration, however, further information on this extension method is not available in OpenJPA documentation. Firstly, how to specify metadata for a interface that has bean-style methods? Possibilities are: a) Annotating the Java interface definition with @Entity b) Specifying in classorg.acme.IPerson/class in persistence.xml Either of the above fails. a) fails at parsing b) fails with no metadata There may be a correct but undocumented way of specifying a managed interface. If that is the case, then this JIRA report should be treated as a documentation bug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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_12473285
]
Craig Russell commented on OPENJPA-141:
---
If we want a hard cache that drops entries for classes that are
redeployed, then
we should be using weak keys and hard values. If we want a memory
sensitive
cache, then we should be using hard keys and soft values.
I vaguely prefer a hard cache that drops entries for classes that are
redeployed, since I care more about speed than memory footprint.
This is also affected by whether we use a giant cache (including all the EMFs)
or one cache per EMF. I prefer one cache per EMF because it simplifies the
cache entry life cycle. During EMF close, the cache can be explicitly cleared,
which allows the garbage collector to be more efficient since it doesn't have
to scan all the entries in the cache.
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
Attachments: openjpa-141.txt
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.
[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_12472795
]
Craig Russell commented on OPENJPA-141:
---
Nice work, Kevin and Abe.
Just a reminder. Please attach an svn patch to this JIRA when it's ready. I'd
like to be able to see the patch right along side this discussion here. And
when the patch is committed, please put OPENJPA-141 into the commit comments so
svn will back link to this page. Thanks.
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 =
[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_12472829
]
Craig Russell commented on OPENJPA-141:
---
Given the number of iterations already documented on this issue, wouldn't it be
better to attach the real patch here for review?
In other words, this issue might be a case of review then commit instead of
our normal commit then review approach.
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
[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
you're trying to do from a memory management perspective. For the
_assignableTypes member you've got the Class keys
[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 (b) if this is working, it's again only because of
some JVM particulars or GC timing particulars or testing particulars
(I've seen
[jira] Commented: (OPENJPA-135) join fetch not returning duplicate references which not conforming to ejb3.0 spec
[ https://issues.apache.org/jira/browse/OPENJPA-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471518 ] Craig Russell commented on OPENJPA-135: --- Would it be possible for you to attach a simple test case to this issue? Thanks. join fetch not returning duplicate references which not conforming to ejb3.0 spec - Key: OPENJPA-135 URL: https://issues.apache.org/jira/browse/OPENJPA-135 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Catalina Wei In the description in EJB 3.0 JPA spec, section 4.4.5.3, the following query example SELECT d FROM Department d LEFT JOIN FETCH d.employees WHERE d.deptno = 1 The spec says this query returns 5 references to the department 1 entity if department 1 has 5 employees. The same query running with openjpa code, it returns only 1 reference to department 1 entity. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-117) Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection
[ https://issues.apache.org/jira/browse/OPENJPA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470294 ] Craig Russell commented on OPENJPA-117: --- Maybe this case would best be handled by having the TransactionListener itself register for the event. I'm assuming that the listener is stateful and is listening on a specific Broker. Then add a method on the TransactionListenerImpl like void listenOn(Broker broker). If it is already listening on the parameter, it returns. Otherwise it registers itself. This can be exended if a listener can listen on multiple Brokers. In that case, the listener can manage a Set of Brokers that it is listening on. I'm not so concerned about different users of a Broker getting information about other users. As Abe points out, all the actors who share a Broker are already intimately connected, and any one can cause damage. So it's not about isolation, it's more about separation of concerns. In this case, why should an actor care if a listener is already listening? The listener can be active making sure it's not registered multiple times with the same Broker. Collection of TransactionListeners registered to a Broker should be available as unmodifiable collection Key: OPENJPA-117 URL: https://issues.apache.org/jira/browse/OPENJPA-117 Project: OpenJPA Issue Type: Improvement Components: kernel Reporter: Pinaki Poddar Assigned To: Pinaki Poddar Priority: Minor Currently TransactionListeners can be added/removed to a broker but the list of transaction listeners registered to a particular broker is not available. Such a collection can be made available in read-only mode so a caller can determine whether to add a new listener or not, or whether a particular listener is already registered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-115) Bottleneck(s) with using OpenJPA in a Container-managed environment
[ https://issues.apache.org/jira/browse/OPENJPA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469604 ] Craig Russell commented on OPENJPA-115: --- Yes, null checking is an expected requirement when dealing with weak references. If you can get a strong reference in a cleanup routine then it's ok to use it, because the fact that you have a strong reference will prevent garbage collection. If you get null from your weak reference, then the garbage collector has already done its job and by definition there can be nothing left for your routine to clean up. Bottleneck(s) with using OpenJPA in a Container-managed environment --- Key: OPENJPA-115 URL: https://issues.apache.org/jira/browse/OPENJPA-115 Project: OpenJPA Issue Type: Bug Components: kernel Reporter: Kevin Sutter Assigned To: Kevin Sutter Priority: Critical Running some benchmarks against OpenJPA using the Sun Java System (SunOne) application server. Under load, we're not able to push the cpu to 100%. The culprit seems to be the lock and synchronization processing within AbstractBrokerFactory.newBroker(..). According to sections 5.9.1 and 5.9.2 in the JPA specification, it looks like OpenJPA is attempting to do too much management of the created EntityManagers. Within a Container-managed environment, the Container takes care of the lifecycle of the EntityManagers. So, there does not seem to be a need to do the findBroker(..) invocation, nor is there a need to keep track of the created EntityManagers (_brokers) so that they can be closed when the Factory is closed. Once we have verified these changes, there may be others that are needed. But, we have to get by this bottleneck first before going to the next layer... Kevin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-122) EntityManager does not throw exceptions after close() in required cases
EntityManager does not throw exceptions after close() in required cases --- Key: OPENJPA-122 URL: https://issues.apache.org/jira/browse/OPENJPA-122 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Craig Russell Priority: Minor A new test case TestEntityManagerMethodsThrowAfterClose has 2 failures and 2 errors. The test case has not been checked in so that the build does not fail. The test case is attached. 1. Wrong exception thrown for flush after close: testFlushAfterClose(org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose) Time elapsed: 1.294 sec ERROR! 4|false|0.9.7-incubating-SNAPSHOT org.apache.openjpa.persistence.TransactionRequiredException: Can only perform operation while a transaction is active. at org.apache.openjpa.kernel.BrokerImpl.assertActiveTransaction(BrokerImpl.java:4252) at org.apache.openjpa.kernel.DelegatingBroker.assertActiveTransaction(DelegatingBroker.java:1292) at org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:472) at org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose.testFlushAfterClose(TestEntityManagerMethodsThrowAfterClose.java:113) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) 2. No exception thrown for setFlushMode after close: testSetFlushModeAfterClose(org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose) Time elapsed: 0.338 sec FAILURE! junit.framework.AssertionFailedError: Expected exception for method setFlushMode after em.close() at junit.framework.Assert.fail(Assert.java:47) at org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose.testSetFlushModeAfterClose(TestEntityManagerMethodsThrowAfterClose.java:123) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at
[jira] Updated: (OPENJPA-122) EntityManager does not throw exceptions after close() in required cases
[ https://issues.apache.org/jira/browse/OPENJPA-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Craig Russell updated OPENJPA-122: -- Attachment: EntityManagerImpl.patch.txt Please review this patch. This patch fixes the issue but I'd like to have it reviewed. EntityManager does not throw exceptions after close() in required cases --- Key: OPENJPA-122 URL: https://issues.apache.org/jira/browse/OPENJPA-122 Project: OpenJPA Issue Type: Bug Components: jpa Reporter: Craig Russell Priority: Minor Attachments: EntityManagerImpl.patch.txt, TestEntityManagerMethodsThrowAfterClose.java A new test case TestEntityManagerMethodsThrowAfterClose has 2 failures and 2 errors. The test case has not been checked in so that the build does not fail. The test case is attached. 1. Wrong exception thrown for flush after close: testFlushAfterClose(org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose) Time elapsed: 1.294 sec ERROR! 4|false|0.9.7-incubating-SNAPSHOT org.apache.openjpa.persistence.TransactionRequiredException: Can only perform operation while a transaction is active. at org.apache.openjpa.kernel.BrokerImpl.assertActiveTransaction(BrokerImpl.java:4252) at org.apache.openjpa.kernel.DelegatingBroker.assertActiveTransaction(DelegatingBroker.java:1292) at org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:472) at org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose.testFlushAfterClose(TestEntityManagerMethodsThrowAfterClose.java:113) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122) at org.apache.maven.surefire.Surefire.run(Surefire.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747) 2. No exception thrown for setFlushMode after close: testSetFlushModeAfterClose(org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose) Time elapsed: 0.338 sec FAILURE! junit.framework.AssertionFailedError: Expected exception for method setFlushMode after em.close() at junit.framework.Assert.fail(Assert.java:47) at org.apache.openjpa.persistence.simple.TestEntityManagerMethodsThrowAfterClose.testSetFlushModeAfterClose(TestEntityManagerMethodsThrowAfterClose.java:123) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at
[jira] Commented: (OPENJPA-115) Bottleneck(s) with using OpenJPA in a Container-managed environment
[ https://issues.apache.org/jira/browse/OPENJPA-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468408 ] Craig Russell commented on OPENJPA-115: --- Kevin opined: Within a Container-managed environment, the Container takes care of the lifecycle of the EntityManagers. I believe that this applies only to injected EntityManagers, not to those created by the user explicitly via EMF.createEntityManager. So there is still some cleanup needed to guarantee proper resource deallocation when the EMF is closed. Patrick offered: implement a concurrent Collection class that uses weak references, and eliminate all locking I believe that this is an optimal solution. Concurrent Collections should have almost zero locking in most containers. Bottleneck(s) with using OpenJPA in a Container-managed environment --- Key: OPENJPA-115 URL: https://issues.apache.org/jira/browse/OPENJPA-115 Project: OpenJPA Issue Type: Bug Components: kernel Reporter: Kevin Sutter Assigned To: Kevin Sutter Priority: Critical Running some benchmarks against OpenJPA using the Sun Java System (SunOne) application server. Under load, we're not able to push the cpu to 100%. The culprit seems to be the lock and synchronization processing within AbstractBrokerFactory.newBroker(..). According to sections 5.9.1 and 5.9.2 in the JPA specification, it looks like OpenJPA is attempting to do too much management of the created EntityManagers. Within a Container-managed environment, the Container takes care of the lifecycle of the EntityManagers. So, there does not seem to be a need to do the findBroker(..) invocation, nor is there a need to keep track of the created EntityManagers (_brokers) so that they can be closed when the Factory is closed. Once we have verified these changes, there may be others that are needed. But, we have to get by this bottleneck first before going to the next layer... Kevin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-99) Enhanced pcNewInstance redundantly clears fields
Enhanced pcNewInstance redundantly clears fields - Key: OPENJPA-99 URL: https://issues.apache.org/jira/browse/OPENJPA-99 Project: OpenJPA Issue Type: Bug Components: kernel Reporter: Craig Russell This exception occurs when using an Entity with a not-null requirement for the object id field. During creation of the Entity via the enhancer-generated method pcNewInstance, the enhancer-generated method pcClearFields iterates fields and invokes the enhancer-modified setter method with the Java default value (null for reference types). The user's setter method enforces not-null values and throws an exception. I think that there is no need to have the pcNewInstance call the pcClearFields method to set values for fields that have already been set to their Java default values. In addition to the not-null requirement (which is not illegal according to the JPA specification) this behavior also affects performance. Redundantly setting fields is a waste of CPU. [java] 0|false|0.9.6-incubating org.apache.openjpa.persistence.PersistenceException: null [java] at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:851) [java] at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:743) [java] at org.apache.openjpa.kernel.DelegatingBroker.find(DelegatingBroker.java:169) [java] at org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:320) [java] at pb.adapter.EJB3Adapter.lookupComponent(EJB3Adapter.java:254) [java] at pb.common.InternalDriver.lookupComponent(InternalDriver.java:322) [java] at pb.common.InternalDriver.createRelationships(InternalDriver.java:285) [java] at pb.OCDriver.createRelationships(OCDriver.java:114) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] at java.lang.reflect.Method.invoke(Method.java:585) [java] at com.sun.faban.driver.core.AgentThread.timeRun(AgentThread.java:194) [java] at com.sun.faban.driver.core.AgentThread.run(AgentThread.java:123) [java] Caused by: java.lang.NumberFormatException: null [java] at java.lang.Integer.parseInt(Integer.java:415) [java] at java.lang.Integer.parseInt(Integer.java:497) [java] at pb.common.Component.pcsetId(Component.java:95) [java] at pb.common.Component.pcClearFields(Component.java) [java] at pb.common.Component.pcNewInstance(Component.java) [java] at org.apache.openjpa.enhance.PCRegistry.newInstance(PCRegistry.java:117) [java] at org.apache.openjpa.kernel.StateManagerImpl.initialize(StateManagerImpl.java:247) [java] at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:327) [java] at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:252) [java] at org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:108) [java] at org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:54) [java] at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:870) [java] at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:828) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-81) Bad error message when trying to query a Collection relation using dot notation
[ http://issues.apache.org/jira/browse/OPENJPA-81?page=comments#action_12449748 ] Craig Russell commented on OPENJPA-81: -- Yes, it's illegal and pending a change to the specification (which is unlikely), you should rewrite the query. Craig Bad error message when trying to query a Collection relation using dot notation --- Key: OPENJPA-81 URL: http://issues.apache.org/jira/browse/OPENJPA-81 Project: OpenJPA Issue Type: Improvement Components: diagnostics, query Environment: openJPA 0.9.7 MySQL 5.0.15 Reporter: Jakob Braeuchi Priority: Minor the query over the 1:n relationship 'katergorien' em.createQuery(select distinct k from KategorieGruppe k + where k.kategorien.bezeichnung like ?1 + order by k.bezeichnung asc); uses a wrong alias t2 in the generated SQL: SELECT DISTINCT t0.id, t0.bezeichnung FROM ekv2kategoriegruppe t0 INNER JOIN ekv2kategorie t1 ON t0.id = t1.idGruppe WHERE (t2.bezeichnung LIKE ? ESCAPE '\\') ORDER BY t0.bezeichnung ASC [params=(String) F%] Unknown column 't2.bezeichnung' in 'where clause' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OPENJPA-7) Link to wiki is incorrect in site
[ http://issues.apache.org/jira/browse/OPENJPA-7?page=comments#action_12425925 ] Craig Russell commented on OPENJPA-7: - The site was updated. Waiting for rsync to resolve/close this issue. Link to wiki is incorrect in site - Key: OPENJPA-7 URL: http://issues.apache.org/jira/browse/OPENJPA-7 Project: OpenJPA Issue Type: Bug Reporter: Craig Russell Assigned To: Craig Russell Priority: Minor The wiki link on the homepage is: http://wiki.apache.org/incubator/OpenJPA%20wiki and should be http://wiki.apache.org/incubator/OpenJPA Contributed by Dion Gillard -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
