[jira] Resolved: (OPENJPA-71) Caching primitive array types consumes excessive memory

2007-03-08 Thread Patrick Linskey (JIRA)

 [ 
https://issues.apache.org/jira/browse/OPENJPA-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-71.


   Resolution: Fixed
Fix Version/s: (was: 0.9.7)

 Caching primitive array types consumes excessive memory
 ---

 Key: OPENJPA-71
 URL: https://issues.apache.org/jira/browse/OPENJPA-71
 Project: OpenJPA
  Issue Type: Bug
  Components: datacache
Reporter: Roger Keays

 As reported on the mailing list: 
 http://www.nabble.com/cached-byte---consumes-excessive-memory-tf2543098.html 
 , in org.apache.openjpa.AbstractPCData#toData() an ArrayList is used to cache 
 all types of arrays, including arrays of primitives. This can use excessively 
 large amounts of memory because of the wrappers required for each element in 
 the array. In one test case, a 7MB byte[] consumed 127MB when converted to a 
 cached ArrayList.
 AbstractPCData needs to be fixed to handle simple arrays.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (OPENJPA-46) true, false not case insensitive, gets null pointer exception

2007-03-08 Thread Patrick Linskey (JIRA)

 [ 
https://issues.apache.org/jira/browse/OPENJPA-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Linskey resolved OPENJPA-46.


   Resolution: Fixed
Fix Version/s: (was: 0.9.7)
 Assignee: (was: Patrick Linskey)

 true, false not case insensitive, gets null pointer exception
 -

 Key: OPENJPA-46
 URL: https://issues.apache.org/jira/browse/OPENJPA-46
 Project: OpenJPA
  Issue Type: Bug
  Components: query
 Environment: windows xp, derby, db2 
Reporter: George Hongell
Priority: Minor
 Attachments: failureEntities.jar


 140 - true,false should be case insensitive - gets npe
   [ FAILED 140- bucket = fvtfull, query = select e from EmpBean e where 
 (e.isManager = True)  : 
EXPECTED(
  TEST140; select e from EmpBean e where (e.isManager = True) 
 [( class com.dw.test.EmpBean  empid=2 name=andrew salary=13.1 dept=210)]
 [( class com.dw.test.EmpBean  empid=1 name=david salary=12.1 dept=210)]
  TEST140; 2 tuples ) 
ACTUAL(
  TEST140; select e from EmpBean e where (e.isManager = True) 
  e   
  
 null 
  TEST140; 1 tuple) ]
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:672)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:934)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
   ... 23 more
 4|false|0.0.0 org.apache.openjpa.persistence.ArgumentException: null
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:755)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:716)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:712)
   at 
 org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:512)
   at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:216)
   at 
 org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:254)
   at 
 com.ibm.ws.query.utils.JFLoopQueryTestcase.createAndRunQuery(JFLoopQueryTestcase.java:187)
   at 
 com.ibm.ws.query.utils.JFLoopQueryTestcase.testFileQuery(JFLoopQueryTestcase.java:536)
   at 
 com.ibm.ws.query.utils.JFLoopQueryTestcase.testRunQueryLoopImpl(JFLoopQueryTestcase.java:591)
   at 
 com.ibm.ws.query.tests.JFLoopQueryTest.testRunQueryLoop(JFLoopQueryTest.java:265)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:615)
   at 
 junit.extensions.jfunc.TestletWrapper.runBare(TestletWrapper.java:116)
   at 
 junit.extensions.jfunc.TestletWrapper$1.protect(TestletWrapper.java:106)
   at junit.framework.TestResult.runProtected(Unknown Source)
   at junit.extensions.jfunc.TestletWrapper.run(TestletWrapper.java:109)
   at junit.framework.TestSuite.runTest(Unknown Source)
   at junit.framework.TestSuite.run(Unknown Source)
   at junit.extensions.jfunc.JFuncSuite.run(JFuncSuite.java:134)
   at junit.extensions.jfunc.textui.JFuncRunner.doRun(JFuncRunner.java:76)
   at junit.extensions.jfunc.textui.JFuncRunner.start(JFuncRunner.java:398)
   at junit.extensions.jfunc.textui.JFuncRunner.main(JFuncRunner.java:218)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.openjpa.jdbc.kernel.exps.PCPath.initialize(PCPath.java:362)
   at 
 org.apache.openjpa.jdbc.kernel.exps.CompareEqualExpression.initialize(CompareEqualExpression.java:78)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.initialize(SelectConstructor.java:166)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.newSelect(SelectConstructor.java:115)
   at 
 org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:69)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.createWhereSelects(JDBCStoreQuery.java:324)
   at 
 org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeQuery(JDBCStoreQuery.java:165)
   at 
 org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:672)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:934)
   at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:746)
   ... 23 more
 141 same
  TEST141; select e from EmpBean e where (e.isManager = fAlSe) 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: @Dependent annotation vs cascade=ALL

2007-03-08 Thread Abe White
Thanks, Abe.  This explanation helps a great deal.  Should we  
update the

documentation with some of this information?


As far as I can tell the documentation on cascade=DELETE and the  
documentation on the Dependent metadata extension already contains  
everything I said.  Feel free to change it, though.

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


Re: @Dependent annotation vs cascade=ALL

2007-03-08 Thread Craig L Russell

Hi Kevin,

On Mar 8, 2007, at 8:45 AM, Kevin Sutter wrote:


Abe,
Your explanation in your reply was much clearer (IMHO) than the  
current
documentation.  I will take a stab at improving the wording so that  
the

meaning and differences are more pronounced.  I will also link the two
sections of the document.  Thanks.

One clarification...  Using Magazine and Article from the doc's  
example, if
a field (Article) is marked as @Dependent and the owning object  
(Magazine)
is deleted, then cascading this delete operation down to the  
Article object

is the same as specifying cascade=REMOVE (or ALL) on the relationship
annotation.  Correct?


Yes. From the perspective of the remove behavior, cascade=REMOVE or  
@Dependent will have the same effect.



It seems that the added benefit of the @Dependent
family of annotations is to aid with the orphan object deletion  
when the

Article field is just nulled out.


Right. Usually, dependent relationships are modeled as one-to-many  
relationships, but they apply equally to single-valued relationships.  
As far as I know, they have no value when used with many-to-  
relationships, though.


Craig


Thanks,
Kevin

On 3/8/07, Abe White [EMAIL PROTECTED] wrote:


 Thanks, Abe.  This explanation helps a great deal.  Should we
 update the
 documentation with some of this information?

As far as I can tell the documentation on cascade=DELETE and the
documentation on the Dependent metadata extension already contains
everything I said.  Feel free to change it, though.
_ 
__
Notice:  This email message, together with any attachments, may  
contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and   
affiliated
entities,  that may be confidential,  proprietary,  copyrighted   
and/or
legally privileged, and is intended solely for the use of the  
individual
or entity named in this message. If you are not the intended  
recipient,
and have received this message in error, please immediately return  
this

by email and then delete it.



Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature