RE: Unnecesery INNER JOIN
From the looks of what you have in your query, there has to be a join of some
kind. You are trying to get the id of class A that is associated with
class B. If this is not your desire, what are you trying to do?
-Original Message-
From: QkI [mailto:kukis...@gmail.com]
Sent: Thursday, July 15, 2010 8:19 AM
To: users@openjpa.apache.org
Subject: Unnecesery INNER JOIN
Hi,
Let's say I have the following persistence class:
@Entity
public class B {
@OneToOne(cascade = CascadeType.PERSIST, fetch = FetchType.LAZY)
@JoinColumn(name = a_id)
private A a;
}
and when I try to execute this JPA query:
SELECT b.a.id FROM B where B.id = 123
my SQL output looks like:
SELECT t1.id FROM table_b t0 INNER JOIN table_a t1 ON t0.a_id = t1.id WHERE
(t0.id = 123)
Why does openJPA add unnecesery JOIN to the SQL query.
Can I somehow change this behaviour of openJPA
Thanks,
QkI
--
View this message in context:
http://openjpa.208410.n2.nabble.com/Unnecesery-INNER-JOIN-tp5297321p5297321.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
CONFIDENTIALITY NOTICE: The information contained in this electronic mail
(email) transmission (including attachments), is intended by MCLANE ADVANCED
TECHNOLOGIES for the use of the named individual or entity to which it is
addressed and may contain information that is privileged, confidential and/or
protected as a trade secret. It is not intended for transmission to, or receipt
by, any individual or entity other than the named addressee(s). If you have
received this email in error, please delete it (including attachments) and any
copies thereof without printing, copying or forwarding it, and notify the
sender of the error by email reply immediately.
RE: JPA 3.0
I have never tried to use JPA with Stored Procedures so excuse my ignorance. If it is difficult or not available, it would benefit the spec if JPA would easily use stored procedures and views just like it uses tables. The only thing I think would need to be added to a marked-up Entity Object is something like a stored procedure input annotation. Example: @Column(name = admid, nullable=false, length=10) @Id @ProcedureInput(procedurename = sp1 name = somename1, length = 10) @ProcedureInput(procedurename = sp2 name = somename2, length = 10) private String id; Just a suggestion. Hopefully it can spark some good discussion. -Original Message- From: Daniel Toffetti [mailto:dto...@yahoo.com.ar] Sent: Friday, June 25, 2010 7:46 PM To: users@openjpa.apache.org Subject: RE: JPA 3.0 Hi, Sorry I'm late but I don't want to miss this party... :-) I want to join Chris in his feelings, but pointing out that perhaps what I would most likely want to see is a JDBC 5 rather than a JPA 3. I'll try to be more specific: - I agree I'm not interested in the entity state, I just want detached entities. - I don't want to configure mappings, I just want table rows as objects, anemic model is what some people call it. If there is a tool that can generate the corresponding Java code, better yet. - I don't want to write JDBC boilerplate code, things like Spring JDBC templates or similar would be appreciated (but without Spring !). - Our databases make heavy use of stored procedures, setting IN params, getting OUT params and a list of entities should be trivial. Spring SP templates comes to mind (but without Spring !). Some time ago I started a quest for a magic tool, I searched SourceForge, GoogleCode, FreshMeat and Kenai for keywords like SQL, JDBC, JPA, DAO, ORM, Stored Procedure, etc. I've found and downloaded about eighty projects, most with source code, most barely useable. Some of them attempt to avoid OR mapping, some attempt to do it but better. Data access tools and libraries pop everywhere you move a rock, I guess this says something about the situation. The first time I learnt about ORM, I got scared and horrified... like, you mean no SPs ? I've come to understand the scenarios where ORM and JPA have its place, I don't think JPA is faulty. It's just that I want something different, some tool that assumes I'm working with an RDBMS and want to use it as such. Thanks in advance for any useful tool or URL I might have missed. Cheers, Daniel -- View this message in context: http://openjpa.208410.n2.nabble.com/JPA-3-0-tp5036154p5224183.html Sent from the OpenJPA Users mailing list archive at Nabble.com. CONFIDENTIALITY NOTICE: The information contained in this electronic mail (email) transmission (including attachments), is intended by MCLANE ADVANCED TECHNOLOGIES for the use of the named individual or entity to which it is addressed and may contain information that is privileged, confidential and/or protected as a trade secret. It is not intended for transmission to, or receipt by, any individual or entity other than the named addressee(s). If you have received this email in error, please delete it (including attachments) and any copies thereof without printing, copying or forwarding it, and notify the sender of the error by email reply immediately.
OpenJPA 2.0 vs 1.2
I could not find this information so I apologize if there has been a discussion and I missed it. Basically what I am wondering is if OpenJPA 2.0 is backward compatible with OpenJPA 1.2. If I were to upgrade my OpenJPA to 2.0 would I need to change the code that I have to make it conform to the new 2.0 specification? Russell Collins Sr. Software Engineer McLane Advanced Technology 254.771.6419 [cid:image001.jpg@01CAC9D0.B0DBB610] Do or do not, there is no try. - Yoda CONFIDENTIALITY NOTICE: The information contained in this electronic mail (email) transmission (including attachments), is intended by MCLANE ADVANCED TECHNOLOGIES for the use of the named individual or entity to which it is addressed and may contain information that is privileged, confidential and/or protected as a trade secret. It is not intended for transmission to, or receipt by, any individual or entity other than the named addressee(s). If you have received this email in error, please delete it (including attachments) and any copies thereof without printing, copying or forwarding it, and notify the sender of the error by email reply immediately.
RE: MySQL 4.1.22 + Native Query = Callable statements not supported
Have you tried using a different MySQL driver? I ran into general database issues when trying to use MySQL 4.X with the latest greatest MySQL Driver. I now use MySQL connector 3.0.17 and have not had database issues and that includes working with OpenJPA 1.2.1 -Original Message- From: Dinkar Rao [mailto:dinkar.d91411...@gmail.com] Sent: Saturday, February 27, 2010 9:04 PM To: users@openjpa.apache.org Subject: MySQL 4.1.22 + Native Query = Callable statements not supported Hi Folks, I have the following setup: MySQL 4.1.22 with database/schema DB2ADMIN (don't ask!) MySQL JDBC connector 5.1.12 OpenJPA-1.2.1 I have a simple native query: EntityManager em = emf.createEntityManager(); em.getTransaction().begin(); Query create = em.createNativeQuery(create table DB2ADMIN.PARENT (a int)); create.executeUpdate(); em.getTransaction().commit(); The exception (callable statements not supported) is pasted below. This happens for any native query, not just one with a delete statement. The nativequery works fine with OpenJPA-2.0.0-beta with the same MySQL db and the same MySQL driver. Additionally, DB2 + OpenJPA-1.2.1 also works fine. So it's a combination of MySQL JDBC connector 5.1.12 + OpenJPA 1.2.1 that is behaving strangely. If I run a separate Java program that creates its own JDBC connection using the same MySQL driver, the CREATE TABLE and subsequent DELETE FROM statement work fine. So it's not a driver problem. Any suggestions on how to get the native query working ? (Aside: I saw a similar nativequery+delete issue [1] that resulted in OPENJPA-459. It has been fixed in trunk, and I tested that it works fine with the MySQL 5.1.12 driver. Unfortunately, I am in a production environment and cannot move to that release. I backported OPENJPA-459 (commit 835257) from trunk to OpenJPA-1.2.1 in my local workspace, but that did not fix the nativequery problem, so something else fixed it in trunk. OPENJPA-459 is probably not even related to this problem.) The testcase is pasted below. Thanks, Dinkar [1] http://n2.nabble.com/Native-DELETE-on-MySQL-td217583.html#a217583 Exception with OpenJPA-1.2.1: openjpa-1.2.1-r752877:753278 nonfatal general error org.apache.openjpa.persistence.PersistenceException: Callable statements not supported. at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4232) at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4197) at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102) at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:88) at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:64) at org.apache.openjpa.jdbc.kernel.SQLStoreQuery$SQLExecutor.executeUpdate(SQLStoreQuery.java:237) at org.apache.openjpa.kernel.QueryImpl.update(QueryImpl.java:1039) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:809) at org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:884) at org.apache.openjpa.kernel.QueryImpl.updateAll(QueryImpl.java:880) at org.apache.openjpa.kernel.DelegatingQuery.updateAll(DelegatingQuery.java:565) at org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:339) at org.apache.openjpa.persistence.MySQLNativeTest.testNativeCreateTable(MySQLNativeTest.java:28) 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:592) 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 org.apache.openjpa.persistence.test.PersistenceTestCase.run(PersistenceTestCase.java:132) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by:
RE: ClassCastException in pcReplaceField
Honestly, you are probably correct in that all you need is a hashCode and equals for a Set. I guess the real question is, what implementation of Set is being returned by OpenJPA? If it is a TreeSet (most common), then we are on the same page since TreeSet is an implementation of an ordered collection with the following hierarchy. Set - SortedSet - NavigableSet - TreeSet I guess I am saying that you would need to use Comparable because I have not used any of the other implementations and TreeSet is the most common. -Original Message- From: craig.russ...@sun.com [mailto:craig.russ...@sun.com] Sent: Thursday, January 21, 2010 9:45 PM To: users@openjpa.apache.org Subject: Re: ClassCastException in pcReplaceField Hi, On Jan 21, 2010, at 7:23 PM, Russell Collins wrote: While the initial thought is that the equals() method would work, the specification for Set requires a compareTo method be present by implementing the Comparable interface. This is not my understanding. Set requires only hashCode and equals. Ordered collections (e.g. TreeSet) require the elements to implement Comparable or to have a Comparator specified at creation. Maybe we're reading different parts of the spec... Craig Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@sun.com P.S. A good JDO? O, Gasp! CONFIDENTIALITY NOTICE: The information contained in this electronic mail (email) transmission (including attachments), is intended by MCLANE ADVANCED TECHNOLOGIES for the use of the named individual or entity to which it is addressed and may contain information that is privileged, confidential and/or protected as a trade secret. It is not intended for transmission to, or receipt by, any individual or entity other than the named addressee(s). If you have received this email in error, please delete it (including attachments) and any copies thereof without printing, copying or forwarding it, and notify the sender of the error by email reply immediately.
RE: ClassCastException in pcReplaceField
Based on the code that has been provided I am making the assumption that you are mapping your OneToMany to a Set collection. If this is the case, a Set collection will not allow duplicates. In order to check for duplicates, an object that is getting placed in the Set needs to show how it is unique. Therefore the objects that are going into the Set collection need to implement the Comparable (Sorry about IComparable) interface to be inserted. In this case, you would need object B to implement the Comparable interface. You would not need object A to implement Comparable as the comparisons are done on the instances of object B. If you are still getting cast errors, then it is probably something else. You could also try changing the Set collection type to a List to see if you get this error and you would not need to implement the Comparable interface. Remember that a List collection can contain duplicates. -Original Message- From: Udi [mailto:saba...@gmail.com] Sent: Sunday, January 17, 2010 1:07 AM To: users@openjpa.apache.org Subject: RE: ClassCastException in pcReplaceField P.S. - I forgot to mention that I'm enhanching at runtime using javaagent. -- View this message in context: http://n2.nabble.com/ClassCastException-in-pcReplaceField-tp4392185p4407523.html Sent from the OpenJPA Users mailing list archive at Nabble.com. CONFIDENTIALITY NOTICE: The information contained in this electronic mail (email) transmission (including attachments), is intended by MCLANE ADVANCED TECHNOLOGIES for the use of the named individual or entity to which it is addressed and may contain information that is privileged, confidential and/or protected as a trade secret. It is not intended for transmission to, or receipt by, any individual or entity other than the named addressee(s). If you have received this email in error, please delete it (including attachments) and any copies thereof without printing, copying or forwarding it, and notify the sender of the error by email reply immediately.
RE: ClassCastException in pcReplaceField
It looks like you are trying to add items to a Set. You will get these casting
exceptions if your classes do not implement the IComparable interface. If they
do implement the interface, then it is another issue.
-Original Message-
From: Rick Curtis [mailto:curti...@gmail.com]
Sent: Thursday, January 14, 2010 5:02 PM
To: users@openjpa.apache.org
Subject: Re: ClassCastException in pcReplaceField
Udi -
You're really going to need to post more information than this for anyone to
figure out what is going on I understand you don't want to post your
application call stack, what about posting a filtered call stack? That might
be a good starting point.
You say you are enhancing your entities at runtime... is that via the
-javaagent or are you using the subclassing support?
--
Thanks,
Rick
On Thu, Jan 14, 2010 at 6:23 AM, Udi saba...@gmail.com wrote:
Hey, first of all, I'm sorry for not pasting the stack - I just can't.
I'm using OpenJPA 1.2.0
I have 2 classes:
class A{
@OneToMany(mappedBy=a)
Set
}
class B{
@ManyToOne
A a;
}
Now, at some point (I can't create a consistent testcase..) I get
ClassCastException: B cannot be cast to A.
The stack (typed, so sorry once again...):
B.pcReplaceField()
StateManagerImpl.replaceField()
StateManagerImpl.storeObjectField()
StateManagerImpl.storeObject()
RelationFieldStrategy.load()
FieldMapping.load()
JDBCStoreManager.load()
I'm enhancing entities at runtime, so I used decompiler to see the
generated
class, and in the problematic line it appears like a cast for a field.
Anyone knows how can it happen (and even more interesting - how to solve
the
problem? :) )
Thanks,
Udi
--
View this message in context:
http://n2.nabble.com/ClassCastException-in-pcReplaceField-tp4392185p4392185.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
CONFIDENTIALITY NOTICE: The information contained in this electronic mail
(email) transmission (including attachments), is intended by MCLANE ADVANCED
TECHNOLOGIES for the use of the named individual or entity to which it is
addressed and may contain information that is privileged, confidential and/or
protected as a trade secret. It is not intended for transmission to, or receipt
by, any individual or entity other than the named addressee(s). If you have
received this email in error, please delete it (including attachments) and any
copies thereof without printing, copying or forwarding it, and notify the
sender of the error by email reply immediately.
RE: openJPA with EJB3 MySQL on WAS7
Just a quick question. Is the table already created or are you trying to use
OpenJPA to create the table?
-Original Message-
From: kpsuk [mailto:keithsec...@yahoo.co.uk]
Sent: Friday, December 04, 2009 9:32 AM
To: users@openjpa.apache.org
Subject: openJPA with EJB3 MySQL on WAS7
Having a little trouble with openJPA persiting with MySQL, whilst new rows
are being created for each em.persist(dao) the rows are bring populated with
'NULL' values for each column!
I get no error in my logs and debugging shows that the property values are
there right upto the em.persist(dao) line of code.
DAO
@Entity
@Table(name = tbl_user_details)
public class UserRegistrationDao implements java.io.Serializable {
private int id;
private String firstname;
private String surname;
private String email;
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name=id)
public int getId() {
return this.id;
}
public void setId(int id) {
this.id = id;
}
@Basic
@Column(name=firstname)
public synchronized final String getFirstname() {
return this.firstname;
}
public synchronized final void setFirstname(String firstname) {
this.firstname = firstname;
}
@Basic
@Column(name=surname)
public synchronized final String getSurname() {
return this.surname;
}
public synchronized final void setSurname(String surname) {
this.surname = surname;
}
@Basic
@Column(name=email)
public synchronized final String getEmail() {
return this.email;
}
public synchronized final void setEmail(String email) {
this.email = email;
}
}
Bean
@PersistenceContext(unitName = users, type =
PersistenceContextType.EXTENDED)
private EntityManager _em;
@Override
public boolean create(MapString, Object args) {
UserRegistrationDao dao = new UserRegistrationDao(args);
_em.persist(dao); // *** upto here values are present ***
persistence.xml
persistence-unit name=users transaction-type=JTA
providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider
jta-data-sourcejdbc/users/jta-data-source
!-- Enumerate your persistent classes here. --
classcom.project1.business.dao.UserRegistrationDao/class
properties
property name=openjpa.ConnectionURL
value=jdbc:mysql://localhost:3306/users/
property name=openjpa.ConnectionDriverName
value=com.mysql.jdbc.Driver/
property name=openjpa.ConnectionUserName
value=root/
property name=openjpa.ConnectionPassword
value=rootpass123/
/properties
/persistence-unit
--
View this message in context:
http://n2.nabble.com/openJPA-with-EJB3-MySQL-on-WAS7-tp4113103p4113103.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
EAO Pattern
This is an open-ended question for everyone on the panel. What is your thoughts on the EAO pattern in a JEE environment? Is it useful? Is it just too much overhead? I am trying to really analyze if this is a viable solution for an enterprise system. Russell Collins Sr. Software Engineer McLane Advanced Technology 254.771.6419 Do or do not, there is no try. - Yoda
RE: FW: Memory leak
Is there a configuration setting or work around for this in the meantime?
Russell Collins
Sr. Software Engineer
McLane Advanced Technology
Do or do not, there is no try. - Yoda
-Original Message-
From: David Minor [mailto:davemi...@gmail.com]
Sent: Wednesday, July 22, 2009 11:12 AM
To: users@openjpa.apache.org; d...@openjpa.apache.org
Subject: Re: FW: Memory leak
I've created http://issues.apache.org/jira/browse/OPENJPA-1193
One thought I had was that the if statement might simply be missing a ! --
since this is a concurrency improvement for non-finalizing brokers, perhaps
the non-finalizing brokers were supposed to be switched to the
ConcurrentHashMap, rather than the finalizing brokers.
Is Patrick Linskey still involved in openjpa? I haven't seen his name for
awhile.
-Original Message-
From: Michael Dick [mailto:michael.d.d...@gmail.com]
Sent: Wednesday, July 22, 2009 6:47 AM
To: users@openjpa.apache.org; d...@openjpa.apache.org
Subject: Re: FW: Memory leak
Hi David,
At the moment I don't have a ton of free time to dive into the change or
the peformance bottleneck that it resolved. In the interest of providing
some relief (trunk 1.3.x) I'd be happy to make this change
configurable (maybe something on openjpa.conf.Compatibility) so you can
get the old behavior.
I've cross posted to d...@openjpa to see if there are any objections.
In any event would you mind opening a JIRA issue (I'd do it but then you
have to subscribe to get notifications etc.).
On Tue, Jul 21, 2009 at 6:37 PM, David Minor davemi...@gmail.com
wrote:
Looks like this code was checked in a year ago by Patrick Linskey with
the comment Improve concurrency by actively managing
AbstractBrokerFactory's broker set when using non-finalizing brokers.
Credit goes to Arunabh Hazarika for identifying the bottleneck and
prototyping this solution.
I'm not sure why _brokers was changed with regards to
FinalizingBrokerImpl though. BrokerImpl's free() method was modified
to call the factory to remove the it from _brokers.
FinalizingBrokerImpl calls free() from its finalizer, but the
finalizer will never be called if there is a reference in _brokers.
Anyone have any ideas?
On Tue, Jul 21, 2009 at 11:24 AM, David Minor davemi...@gmail.com
wrote:
Hi Mike,
I've tracked the problem down to
org.apache.openjpa.kernel.AbstractBrokerFactory. The heap dump lists
the _brokers Set as containing all the references to
FinalizingBrokerImpl,
and
it appears the assignment of this set was changed to this:
if (FinalizingBrokerImpl.class.isAssignableFrom(
bv.getTemplateBrokerType(_conf))) {
return MapBackedSet.decorate(new ConcurrentHashMap(),
new Object() { });
} else {
return new ConcurrentReferenceHashSet(
ConcurrentReferenceHashSet.WEAK);
}
It used to be assigned to the weak reference hash set as in the else
statement. Forcing the second assignment fixes the problem.
-Original Message-
From: Michael Dick [mailto:michael.d.d...@gmail.com]
Sent: Tuesday, July 14, 2009 7:29 AM
To: users@openjpa.apache.org
Subject: Re: FW: Memory leak
Hi David,
There have been a few changes in PersistenceProviderImpl. One was
to make the non-finalizing BrokerImpl the default (must be
overridden in your
config) another that might be interesting was adding a pool of
EntityManagerFactories.
From what I've seen the EMF pool is not used by default, but it's
possible that the AbstractEntityManagerFactoryBean is setting it
(the property is named EntityManagerFactoryPool in case that
helps). I took a quick pass at setting the pooling property and
the only way I saw it take effect was to pass it in as a JVM arg
(might be something in my eclipse env though - and I'm on
2.0.0-SNAPSHOT ATM).
Hope this gives you a starting point, if not keep replying and
we'll
try
to help
-mike
On Mon, Jul 13, 2009 at 8:00 PM, David Minor davemi...@gmail.com
wrote:
Hi Mike,
Nothing else has changed. The application extends spring 2.0's
AbstractEntityManagerFactoryBean class (apparently so that the
persistence.xml file can be named something different).
I notice it is checking the return type of
AbstractEntityManagerFactoryBean's getPersistenceProvider() for
an instance of openjpa's PersistenceProviderImpl, and doing
something different depending on whether it finds it or not. Has
anything changed with regards to this class?
-Original Message-
From: Michael Dick [mailto:michael.d.d...@gmail.com]
Sent: Monday, July 13, 2009 12:49 PM
To: users@openjpa.apache.org
Subject: Re: Memory leak
Hi David,
FinalizingBrokerImpl will close itself and free resources when
RE: FW: Memory leak
I am using the openjpa within the Geronimo container. Is there a way that I
can tell Geronimo to do this or is this a question for the Geronimo group?
Russell Collins
Sr. Software Engineer
McLane Advanced Technology
Do or do not, there is no try. - Yoda
-Original Message-
From: Patrick Linskey [mailto:plins...@gmail.com]
Sent: Wednesday, July 22, 2009 6:58 PM
To: users@openjpa.apache.org
Subject: Re: FW: Memory leak
Hi,
Is there any particular reason why you need the finalizing broker? One
(vastly preferable) option would be to use the non-finalizing broker,
which, of course, means that you're promising to close your brokers at
the appropriate lifecycle moments.
Certainly, the bug deserves to be addressed, as the whole point of the
finalizing mode is to be robust in an environment with dubious cleanup
practices.
-Patrick
On Wed, Jul 22, 2009 at 4:15 PM, Russell
Collinsrussell.coll...@mclaneat.com wrote:
Is there a configuration setting or work around for this in the meantime?
Russell Collins
Sr. Software Engineer
McLane Advanced Technology
Do or do not, there is no try. - Yoda
-Original Message-
From: David Minor [mailto:davemi...@gmail.com]
Sent: Wednesday, July 22, 2009 11:12 AM
To: users@openjpa.apache.org; d...@openjpa.apache.org
Subject: Re: FW: Memory leak
I've created http://issues.apache.org/jira/browse/OPENJPA-1193
One thought I had was that the if statement might simply be missing a ! --
since this is a concurrency improvement for non-finalizing brokers, perhaps
the non-finalizing brokers were supposed to be switched to the
ConcurrentHashMap, rather than the finalizing brokers.
Is Patrick Linskey still involved in openjpa? I haven't seen his name for
awhile.
-Original Message-
From: Michael Dick [mailto:michael.d.d...@gmail.com]
Sent: Wednesday, July 22, 2009 6:47 AM
To: users@openjpa.apache.org; d...@openjpa.apache.org
Subject: Re: FW: Memory leak
Hi David,
At the moment I don't have a ton of free time to dive into the change or
the peformance bottleneck that it resolved. In the interest of providing
some relief (trunk 1.3.x) I'd be happy to make this change
configurable (maybe something on openjpa.conf.Compatibility) so you can
get the old behavior.
I've cross posted to d...@openjpa to see if there are any objections.
In any event would you mind opening a JIRA issue (I'd do it but then you
have to subscribe to get notifications etc.).
On Tue, Jul 21, 2009 at 6:37 PM, David Minor davemi...@gmail.com
wrote:
Looks like this code was checked in a year ago by Patrick Linskey with
the comment Improve concurrency by actively managing
AbstractBrokerFactory's broker set when using non-finalizing brokers.
Credit goes to Arunabh Hazarika for identifying the bottleneck and
prototyping this solution.
I'm not sure why _brokers was changed with regards to
FinalizingBrokerImpl though. BrokerImpl's free() method was modified
to call the factory to remove the it from _brokers.
FinalizingBrokerImpl calls free() from its finalizer, but the
finalizer will never be called if there is a reference in _brokers.
Anyone have any ideas?
On Tue, Jul 21, 2009 at 11:24 AM, David Minor davemi...@gmail.com
wrote:
Hi Mike,
I've tracked the problem down to
org.apache.openjpa.kernel.AbstractBrokerFactory. The heap dump lists
the _brokers Set as containing all the references to
FinalizingBrokerImpl,
and
it appears the assignment of this set was changed to this:
if (FinalizingBrokerImpl.class.isAssignableFrom(
bv.getTemplateBrokerType(_conf))) {
return MapBackedSet.decorate(new ConcurrentHashMap(),
new Object() { });
} else {
return new ConcurrentReferenceHashSet(
ConcurrentReferenceHashSet.WEAK);
}
It used to be assigned to the weak reference hash set as in the else
statement. Forcing the second assignment fixes the problem.
-Original Message-
From: Michael Dick [mailto:michael.d.d...@gmail.com]
Sent: Tuesday, July 14, 2009 7:29 AM
To: users@openjpa.apache.org
Subject: Re: FW: Memory leak
Hi David,
There have been a few changes in PersistenceProviderImpl. One was
to make the non-finalizing BrokerImpl the default (must be
overridden in your
config) another that might be interesting was adding a pool of
EntityManagerFactories.
From what I've seen the EMF pool is not used by default, but it's
possible that the AbstractEntityManagerFactoryBean is setting it
(the property is named EntityManagerFactoryPool in case that
helps). I took a quick pass at setting the pooling property and
the only way I saw it take effect was to pass it in as a JVM arg
(might be something in my eclipse env though - and I'm on
2.0.0-SNAPSHOT ATM).
Hope this gives you a starting point
RE: FW: Memory leak
I am using Geronimo to create my EntityManager.
Russell Collins
Sr. Software Engineer
McLane Advanced Technology
Do or do not, there is no try. - Yoda
-Original Message-
From: Patrick Linskey [mailto:plins...@gmail.com]
Sent: Wednesday, July 22, 2009 7:49 PM
To: users@openjpa.apache.org
Subject: Re: FW: Memory leak
Hi,
How are you getting the EM? IIRC (and no, I'm not looking at the code
right now -- I could be very wrong), OpenJPA uses the non-finalizing
approach automatically when
PersistenceProvider.createContainerEntityManagerFactory() is used.
If your EM / EMF is injected by Geronimo, then Geronimo should be
creating the EMF via this method, so it should automatically be
working. However, if you're manually creating an EMF using
Persistence.createEntityManagerFactory(), Geronimo's lifecycle
management is bypassed.
-Patrick
On Wed, Jul 22, 2009 at 5:26 PM, Russell
Collinsrussell.coll...@mclaneat.com wrote:
I am using the openjpa within the Geronimo container. Is there a way that I
can tell Geronimo to do this or is this a question for the Geronimo group?
Russell Collins
Sr. Software Engineer
McLane Advanced Technology
Do or do not, there is no try. - Yoda
-Original Message-
From: Patrick Linskey [mailto:plins...@gmail.com]
Sent: Wednesday, July 22, 2009 6:58 PM
To: users@openjpa.apache.org
Subject: Re: FW: Memory leak
Hi,
Is there any particular reason why you need the finalizing broker? One
(vastly preferable) option would be to use the non-finalizing broker,
which, of course, means that you're promising to close your brokers at
the appropriate lifecycle moments.
Certainly, the bug deserves to be addressed, as the whole point of the
finalizing mode is to be robust in an environment with dubious cleanup
practices.
-Patrick
On Wed, Jul 22, 2009 at 4:15 PM, Russell
Collinsrussell.coll...@mclaneat.com wrote:
Is there a configuration setting or work around for this in the meantime?
Russell Collins
Sr. Software Engineer
McLane Advanced Technology
Do or do not, there is no try. - Yoda
-Original Message-
From: David Minor [mailto:davemi...@gmail.com]
Sent: Wednesday, July 22, 2009 11:12 AM
To: users@openjpa.apache.org; d...@openjpa.apache.org
Subject: Re: FW: Memory leak
I've created http://issues.apache.org/jira/browse/OPENJPA-1193
One thought I had was that the if statement might simply be missing a ! --
since this is a concurrency improvement for non-finalizing brokers, perhaps
the non-finalizing brokers were supposed to be switched to the
ConcurrentHashMap, rather than the finalizing brokers.
Is Patrick Linskey still involved in openjpa? I haven't seen his name for
awhile.
-Original Message-
From: Michael Dick [mailto:michael.d.d...@gmail.com]
Sent: Wednesday, July 22, 2009 6:47 AM
To: users@openjpa.apache.org; d...@openjpa.apache.org
Subject: Re: FW: Memory leak
Hi David,
At the moment I don't have a ton of free time to dive into the change or
the peformance bottleneck that it resolved. In the interest of providing
some relief (trunk 1.3.x) I'd be happy to make this change
configurable (maybe something on openjpa.conf.Compatibility) so you can
get the old behavior.
I've cross posted to d...@openjpa to see if there are any objections.
In any event would you mind opening a JIRA issue (I'd do it but then you
have to subscribe to get notifications etc.).
On Tue, Jul 21, 2009 at 6:37 PM, David Minor davemi...@gmail.com
wrote:
Looks like this code was checked in a year ago by Patrick Linskey with
the comment Improve concurrency by actively managing
AbstractBrokerFactory's broker set when using non-finalizing brokers.
Credit goes to Arunabh Hazarika for identifying the bottleneck and
prototyping this solution.
I'm not sure why _brokers was changed with regards to
FinalizingBrokerImpl though. BrokerImpl's free() method was modified
to call the factory to remove the it from _brokers.
FinalizingBrokerImpl calls free() from its finalizer, but the
finalizer will never be called if there is a reference in _brokers.
Anyone have any ideas?
On Tue, Jul 21, 2009 at 11:24 AM, David Minor davemi...@gmail.com
wrote:
Hi Mike,
I've tracked the problem down to
org.apache.openjpa.kernel.AbstractBrokerFactory. The heap dump lists
the _brokers Set as containing all the references to
FinalizingBrokerImpl,
and
it appears the assignment of this set was changed to this:
if (FinalizingBrokerImpl.class.isAssignableFrom(
bv.getTemplateBrokerType(_conf))) {
return MapBackedSet.decorate(new ConcurrentHashMap(),
new Object() { });
} else {
return new ConcurrentReferenceHashSet(
ConcurrentReferenceHashSet.WEAK);
}
It used to be assigned to the weak reference hash set as in the else
statement. Forcing the second assignment fixes
RE: FW: Memory leak
Correct. Russell Collins Sr. Software Engineer McLane Advanced Technology Do or do not, there is no try. - Yoda -Original Message- From: Patrick Linskey [mailto:plins...@gmail.com] Sent: Wednesday, July 22, 2009 9:43 PM To: users@openjpa.apache.org Subject: Re: FW: Memory leak I am using Geronimo to create my EntityManager. Just to be clear, you're doing so by using an @PersistenceContext annotation or looking up the EntityManager in JNDI, correct? -Patrick On Wed, Jul 22, 2009 at 6:47 PM, Russell Collinsrussell.coll...@mclaneat.com wrote: I am using Geronimo to create my EntityManager. Russell Collins Sr. Software Engineer McLane Advanced Technology Do or do not, there is no try. - Yoda -Original Message- From: Patrick Linskey [mailto:plins...@gmail.com] Sent: Wednesday, July 22, 2009 7:49 PM To: users@openjpa.apache.org Subject: Re: FW: Memory leak Hi, How are you getting the EM? IIRC (and no, I'm not looking at the code right now -- I could be very wrong), OpenJPA uses the non-finalizing approach automatically when PersistenceProvider.createContainerEntityManagerFactory() is used. If your EM / EMF is injected by Geronimo, then Geronimo should be creating the EMF via this method, so it should automatically be working. However, if you're manually creating an EMF using Persistence.createEntityManagerFactory(), Geronimo's lifecycle management is bypassed. -Patrick On Wed, Jul 22, 2009 at 5:26 PM, Russell Collinsrussell.coll...@mclaneat.com wrote: I am using the openjpa within the Geronimo container. Is there a way that I can tell Geronimo to do this or is this a question for the Geronimo group? Russell Collins Sr. Software Engineer McLane Advanced Technology Do or do not, there is no try. - Yoda -Original Message- From: Patrick Linskey [mailto:plins...@gmail.com] Sent: Wednesday, July 22, 2009 6:58 PM To: users@openjpa.apache.org Subject: Re: FW: Memory leak Hi, Is there any particular reason why you need the finalizing broker? One (vastly preferable) option would be to use the non-finalizing broker, which, of course, means that you're promising to close your brokers at the appropriate lifecycle moments. Certainly, the bug deserves to be addressed, as the whole point of the finalizing mode is to be robust in an environment with dubious cleanup practices. -Patrick On Wed, Jul 22, 2009 at 4:15 PM, Russell Collinsrussell.coll...@mclaneat.com wrote: Is there a configuration setting or work around for this in the meantime? Russell Collins Sr. Software Engineer McLane Advanced Technology Do or do not, there is no try. - Yoda -Original Message- From: David Minor [mailto:davemi...@gmail.com] Sent: Wednesday, July 22, 2009 11:12 AM To: users@openjpa.apache.org; d...@openjpa.apache.org Subject: Re: FW: Memory leak I've created http://issues.apache.org/jira/browse/OPENJPA-1193 One thought I had was that the if statement might simply be missing a ! -- since this is a concurrency improvement for non-finalizing brokers, perhaps the non-finalizing brokers were supposed to be switched to the ConcurrentHashMap, rather than the finalizing brokers. Is Patrick Linskey still involved in openjpa? I haven't seen his name for awhile. -Original Message- From: Michael Dick [mailto:michael.d.d...@gmail.com] Sent: Wednesday, July 22, 2009 6:47 AM To: users@openjpa.apache.org; d...@openjpa.apache.org Subject: Re: FW: Memory leak Hi David, At the moment I don't have a ton of free time to dive into the change or the peformance bottleneck that it resolved. In the interest of providing some relief (trunk 1.3.x) I'd be happy to make this change configurable (maybe something on openjpa.conf.Compatibility) so you can get the old behavior. I've cross posted to d...@openjpa to see if there are any objections. In any event would you mind opening a JIRA issue (I'd do it but then you have to subscribe to get notifications etc.). On Tue, Jul 21, 2009 at 6:37 PM, David Minor davemi...@gmail.com wrote: Looks like this code was checked in a year ago by Patrick Linskey with the comment Improve concurrency by actively managing AbstractBrokerFactory's broker set when using non-finalizing brokers. Credit goes to Arunabh Hazarika for identifying the bottleneck and prototyping this solution. I'm not sure why _brokers was changed with regards to FinalizingBrokerImpl though. BrokerImpl's free() method was modified to call the factory to remove the it from _brokers. FinalizingBrokerImpl calls free() from its finalizer, but the finalizer will never be called if there is a reference in _brokers. Anyone have any ideas? On Tue, Jul 21, 2009 at 11:24 AM, David Minor davemi...@gmail.com wrote: Hi Mike, I've tracked the problem down to org.apache.openjpa.kernel.AbstractBrokerFactory. The heap dump lists the _brokers Set as containing all the references
JPA issue
I am having a problem that I believe is associated with the JPA module. I have
created some entity objects and EJB's. When I run through the continuous build
process, it deploys the objects to Geronimo (where OpenJPA is the persistence
layer). The first time I try to access the object, the very first test fails
and the remainder of the tests continue without a problem. When I re-run the
failing test without first deploying, it runs successfully without a problem.
When I look at the log this is what I see that it is trying to do:
15897: 2009-07-22 22:39:24,419 ERROR [root] Error in EntityEmds -
openjpa-1.2.1-r752877:753278 nonfatal general error
org.apache.openjpa.persistence.PersistenceException: Syntax error or access
violation message from server: Access denied for user 'emdsuser'@'%' to
database 'emds' {stmnt 9914713 CREATE TABLE OPENJPASEQ (ID TINYINT NOT NULL,
SEQUENCE_VALUE BIGINT, PRIMARY KEY (ID)) TYPE = innodb} [code=1044, state=42000]
15898: 2009-07-22 22:39:24,419 ERROR [root] openjpa-1.2.1-r752877:753278
nonfatal general error org.apache.openjpa.persistence.PersistenceException:
Syntax error or access violation message from server: Access denied for user
'emdsuser'@'%' to database 'emds' {stmnt 9914713 CREATE TABLE OPENJPASEQ (ID
TINYINT NOT NULL, SEQUENCE_VALUE BIGINT, PRIMARY KEY (ID)) TYPE = innodb}
[code=1044, state=42000]
15899: 2009-07-22 22:39:24,419 ERROR [root] openjpa-1.2.1-r752877:753278
nonfatal general error org.apache.openjpa.persistence.PersistenceException:
Syntax error or access violation message from server: Access denied for user
'emdsuser'@'%' to database 'emds' {stmnt 9914713 CREATE TABLE OPENJPASEQ (ID
TINYINT NOT NULL, SEQUENCE_VALUE BIGINT, PRIMARY KEY (ID)) TYPE = innodb}
[code=1044, state=42000]
16062: 2009-07-22 22:39:37,731 DEBUG [AuthenticatorBase] Security checking
request GET
/console/portal//Server/Server%20Logs/__rp0x3console-base0x2LogViewer!1535651776|1_logFile/C:0xbgeronimo20x210x240x3var0x3log0x3geronimo0x2log/__rp0x3console-base0x2LogViewer!1535651776|1_action/search/__rp0x3console-base0x2LogViewer!1535651776|1_formId/-7251884905713739289/__rp0x3console-base0x2LogViewer!1535651776|1_logLevel/WARN/__rp0x3console-base0x2LogViewer!1535651776|1_maxRows/100
A couple of observations.
1.emdsuser has access to the database. The other ejb runs use the same
userid without any problem. The user does not have the ability to create
tables. The can only do crud activities
2.why is OpenJPA trying to create this table (OPENJPASEQ)? I do not know
where this comes from and I did not tell it to do that.
Any help that you could give me would be greatly appreciated.
RE: Date Problem
Thanks Mike. I included openjpa-1.2.1.jar in my client app and everything
works great.
Russell Collins
Sr. Software Engineer
McLane Advanced Technology
Do or do not, there is no try. - Yoda
-Original Message-
From: Michael Dick [mailto:michael.d.d...@gmail.com]
Sent: Wednesday, May 20, 2009 9:17 AM
To: users@openjpa.apache.org
Subject: Re: Date Problem
Hi Russell,
I think you're hitting the same problem mentioned here [1]. The short
answer is that the client needs to have access to openjpa-1.2.1.jar so it
can load the proxy classes.
The larger question is whether OpenJPA should (or could) serialize to a
non-proxy type to prevent this problem. I don't see the answer in the
previous thread, but some additonal markmail or nabble searching may find
it.
[1] http://markmail.org/thread/2dmgcbnw6yo7b77n
Hope this helps,
-mike
On Wed, May 20, 2009 at 7:18 AM, is_maximum mnr...@gmail.com wrote:
Have you tried java.util.Date instead of java.sql.Date ?
Russell Collins wrote:
Hello, I am new to OpenJPA and the entire persistence objects so bear
with
me a little. First of all, I am using Apache Geronimo which has OpenJPA
version1.2.1 and I am moving from Hibernate (which is a pain to try to
work in Geronimo). Everything works fine except for Dates and Times. I
have an Embedded class that starts off like this:
@Embeddable
public class EntityChange implements Serializable {
private static final long serialVersionUID = 1L;
@Column(name = changedate )
@Temporal(DATE)
private Date changeDate;
@Column(name = changetime)
@Temporal(TIME)
private Time changeTime;
@Column(name = changeuser)
private String changeUser;
When I try to grab an object with these embedded values I get the error:
java.lang.AssertionError: javax.ejb.EJBException: Unknown Container
Exception: java.rmi.RemoteException: Cannot read the response from the
server. The class for an object being returned is not located in this
system:; nested exception is:
java.lang.ClassNotFoundException:
org.apache.openjpa.util.java$sql$Date$proxy
I have tried multiple ways with adding and removing @Temporal etc. Oh
one
more thing, this is a MySQL database that I am trying to access. Please
give me any help you can. Thanks.
Russell Collins
--
View this message in context:
http://n2.nabble.com/Date-Problem-tp2943310p2945766.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Date Problem
Hello, I am new to OpenJPA and the entire persistence objects so bear with me a
little. First of all, I am using Apache Geronimo which has OpenJPA
version1.2.1 and I am moving from Hibernate (which is a pain to try to work in
Geronimo). Everything works fine except for Dates and Times. I have an
Embedded class that starts off like this:
@Embeddable
public class EntityChange implements Serializable {
private static final long serialVersionUID = 1L;
@Column(name = changedate )
@Temporal(DATE)
private Date changeDate;
@Column(name = changetime)
@Temporal(TIME)
private Time changeTime;
@Column(name = changeuser)
private String changeUser;
When I try to grab an object with these embedded values I get the error:
java.lang.AssertionError: javax.ejb.EJBException: Unknown Container Exception:
java.rmi.RemoteException: Cannot read the response from the server. The class
for an object being returned is not located in this system:; nested exception
is:
java.lang.ClassNotFoundException:
org.apache.openjpa.util.java$sql$Date$proxy
I have tried multiple ways with adding and removing @Temporal etc. Oh one more
thing, this is a MySQL database that I am trying to access. Please give me any
help you can. Thanks.
Russell Collins
