Thought inc.

The Dynamic O/R Mapping Company
     

CocoBase Technical Support Forums
For access to developer site with software download and doc's, please request CocoBase download and password
will be emailed to you. Response to posts will appear when answered by THOUGHT Support team.
NOTE:You must register separately with forum in order to post your questions, please click on register icon below.
Home   Frequently Asked Questions   Search   Edit your profile   Registration is free!  
Email This Page to Someone!
Show a Printable Version
CocoBase Enterprise O/R Forums > CocoBase Questions
OutOfMemory on EJB-QL query
< Previous Thread     Next Thread >
Author
Thread    Post New Thread     Post A Reply
joan_caffe
Member

Registered: May 2004
Posts: 5

Hi,

I'm evaluating Cocobase and I get a strange OutOfMemoryException in the following situation:

1. The following query should return about 100 rows/objects (the database has about 500,000 rows):

String query = "SELECT OBJECT(f) FROM HealthProfessionalVO AS f WHERE f.name like 'John%'";
Vector parameters = new Vector();
List result = getCbf().executeQLQuery(query, parameters);

2. Looking at the debug information, the following occurs:

2004-06-20 23:10:11,464 INFO [STDOUT] CocoPowder:: OP=<select> query = select F1,F2,F3,F4,F5,F6,F7,F8,F9,F10,F11 from (SELECT TB_HEALTH_PROF.ID_PERSON_PK AS F1,TB_PERSON.NM_PERSON AS F2,TB_PERSON.CD_CNS AS F3,TB_PERSON.DT_BIRTH AS F4,TB_PERSON.NM_MOTHER AS F5,TB_PERSON.NM_FATHER AS F6,TB_PERSON.CD_PHONE AS F7,TB_PERSON.DS_CONTACT AS F8,TB_PERSON.NM_EMAIL AS F9,TB_PERSON.ID_GENDER_FK AS F10,TB_HEALTH_PROF.DT_STARTED AS F11 FROM TB_PERSON,TB_HEALTH_PROF WHERE (TB_HEALTH_PROF.ID_PERSON_PK=TB_PERSON.ID_PERSON_PK)) T0 where ( ( F2 LIKE 'John%' ) )
2004-06-20 23:10:11,464 INFO [STDOUT] CocoPowder:: Began new command for operation=open_stmt
2004-06-20 23:10:11,464 INFO [STDOUT] CocoPowder:: OP=<open_stmt> Creating new Prepared SQL Statement
2004-06-20 23:10:11,484 INFO [STDOUT] CocoPowder:: OP=<open_stmt> CocoPowder.getPreparedStatement:: localPstmt = oracle.jdbc.driver.OraclePreparedStatement@1424b7b
(...)

So, the query apparently is correct.

3. Cocobase loads all the 'John%' objects and then starts loading ALL the other rows, until an OutOfMemoryException occurs. The debug info below shows this:

2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> Select Next completed - returning true!
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> Added element = true
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> New Object being instantiated - Props = {PHONE=1, EMAIL=john@test.com, GENDER_V_O_ID=1, CNS_CODE=12345, ID=4, CONTACT=Mary, MOTHER_NAME=Mary, NAME=John Smith, FATHER_NAME=Paul}
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> Using Generic factory thought.CocoBase.CBFacadeLocal$InnerFactory@15004dd
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> My new object = CocoProxyM:toString: Wrappered Class=br.com.vidatis.persistence.vo.PersonVO@171bc3f transparent foreign keys={GENDER_V_O_ID=1}
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> Getting next result set record any left.
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> Expecting 11 columns.
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> Selecting column type=4 Position=1
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> result object=10
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> result object class = java.lang.Integer
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> in SelectNext setFields = {}
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> in SelectNext with new element setFields = {ID=10}
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> Select Next completed - returning true!
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> Added element = true
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> Selecting column type=12 Position=2
2004-06-20 23:51:43,547 INFO [STDOUT] CocoPowder:: OP=<open_stmt> result object=Charles Marcus
2004-06-20 23:51:43,557 INFO [STDOUT] CocoPowder:: OP=<open_stmt> result object class = java.lang.String
2004-06-20 23:51:43,557 INFO [STDOUT] CocoPowder:: OP=<open_stmt> in SelectNext setFields = {ID=10}
2004-06-20 23:51:43,557 INFO [STDOUT] CocoPowder:: OP=<open_stmt> in SelectNext with new element setFields = {NAME=Charles Marcus, ID=10}
2004-06-20 23:51:43,557 INFO [STDOUT] CocoPowder:: OP=<open_stmt> Select Next completed - returning true!
2004-06-20 23:51:43,557 INFO [STDOUT] CocoPowder:: OP=<open_stmt> Added element = true
2004-06-20 23:51:43,557 INFO [STDOUT] CocoPowder:: OP=<open_stmt> Selecting column type=12 Position=3
2004-06-20 23:51:43,557 INFO [STDOUT] CocoPowder:: OP=<open_stmt> result object=12345
2004-06-20 23:51:43,557 INFO [STDOUT] CocoPowder:: OP=<open_stmt> result object class = java.lang.String
2004-06-20 23:51:43,557 INFO [STDOUT] CocoPowder:: OP=<open_stmt> in SelectNext setFields = {NAME=Charles Marcus, ID=10}

Here you can see that a person NAME=Charles Marcus has been loaded, when the query selected only the 'John%'.

Is this a bug? Is this a feature that can be disabled?

Thanks in advance.

Joan

06-20-2004 08:06 PM
Click Here to See the Profile for joan_caffe    Find more posts by joan_caffe        Edit/Delete Message    Reply w/Quote    IP: Logged
admin
Administrator

Registered: Apr 2001
Posts: 19

Hi,

Make sure you have "dynamic.querying" in your "cocosource.url" property set to "true" when you connect to the facade. For example:

Properties connectionProperties = new Properties();
connectionProperties.setProperty("cocosource.name","thought.CocoBase.CocoPowderPlugin20");
connectionProperties.setProperty("cocosource.jdbcdriver","oracle.jdbc.driver.OracleDriver");
connectionProperties.setProperty("cocosource.url","jdbc:oracle:thin:@localhost:1521:orcl:cocorep=resource:/Repository.xml:cocoprop=preserve.statements=true,useScrollableCursor=true,dynamic.querying=true");
connectionProperties.setProperty("cocosource.user",jdbc_user);
connectionProperties.setProperty("cocosource.password",jdbc_pwd);
connectionProperties.setProperty("cocosource.navmodel",nav_model);
connectionProperties.setProperty("cocosource.factory","thought.CocoBase.InheritanceFactory");
connectionProperties.setProperty("cbfactory.inheritancemodel",inheritance_model);

CBFacade myBase = CBFacade.create("thought.CocoBase.CBFacadeLocal");
myBase.connect(connectionProperties);


Give that a try and let us know how it works.

Hope that helps!
THOUGHT Support


06-21-2004 06:21 AM
Click Here to See the Profile for admin    Find more posts by admin        Edit/Delete Message    Reply w/Quote    IP: Logged
joan_caffe
Member

Registered: May 2004
Posts: 5
RE: OutOfMemory on EJB-QL query

This is my URL:

try {
if (service == null) {
service = new PersonServiceCocobase();
java.util.Properties prps = new java.util.Properties();
prps.put("cocosource.name","thought.CocoBase.CocoPowder");
prps.put("cocosource.jdbcdriver","oracle.jdbc.driver.OracleDriver");
prps.put("cocosource.url","jdbc:oracle:thin:@127.0.0.1:1521:database;cocorep=resource:/CocoBaseRepository.xml;cocoprop=dynamic.querying=true");
prps.put("cocosource.user","test");
prps.put("cocosource.password","test");
prps.put("cocosource.navmodel","classes_Model");
prps.put("cocosource.debug", "true");
service.init(prps);
}
}catch(Exception e) {
throw new PersistenceException(e);
}

So, dynamic.querying=true. Anything else?

06-21-2004 07:58 AM
Click Here to See the Profile for joan_caffe    Find more posts by joan_caffe        Edit/Delete Message    Reply w/Quote    IP: Logged
admin
Administrator

Registered: Apr 2001
Posts: 19
RE: OutOfMemory on EJB-QL query

Hi,

You connection settings seem correct. Please send the map you are querying against (or send us the entire xml repository if you wish) to support@thoughtinc.com so we can have a better look. Also if you can run your ejb-ql query with debug set to level 5 (e.g. service.setDebugLevel(5)) and send us the trace, that would be helpful. Engineering also recommended that you set "cocosource.name" to use "thought.CocoBase.CocoPowderPlugin20" as this is a later version runtime driver which provides jdbc 2.0 support.

We'll have a look at your test case as soon as we receive your files.

Thanks!
THOUGHT Support

06-21-2004 10:01 AM
Click Here to See the Profile for admin    Find more posts by admin        Edit/Delete Message    Reply w/Quote    IP: Logged
joan_caffe
Member

Registered: May 2004
Posts: 5
RE: OutOfMemory on EJB-QL query

Thanks for your reply.
Before sending you my map file, I tried to change the cocosource.name to thought.CocoBase.CocoPowderPlugin20 and now I get the following exception:

17:55:10,592 INFO [STDOUT] Navigator:: * * * * * Link model verification comple
te! - - - - - - - - - - -
17:55:10,592 INFO [STDOUT] Navigator::
17:55:10,592 INFO [STDOUT] Navigator::
17:55:11,463 ERROR [STDERR] thought.CocoBase.EJBQLCompileException: Runtime not
in dynamic querying mode.
Try setting dynamic.querying=true in the connection URL.
17:55:11,463 ERROR [STDERR] at thought.CocoBase.EJBQLCompiler.<init>(EJBQLCo
mpiler.java:33)
17:55:11,463 ERROR [STDERR] at thought.CocoBase.EJBQLQuery.compile(EJBQLQuer
y.java:87)
17:55:11,463 ERROR [STDERR] at thought.CocoBase.CBFacadeLocal.executeQLQuery
(CBFacadeLocal.java:593)
17:55:11,473 ERROR [STDERR] at persistence.cocobase.PersonServiceCocobase.findByName(PersonServiceCocobase.java:70)
17:55:11,473 ERROR [STDERR] at persistence.cocobase.ejb.ServiceCocobaseBean.findByName(ServiceCocobaseBean.java:93)
17:55:11,473 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(
Native Method)
17:55:11,473 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(N
ativeMethodAccessorImpl.java:39)
17:55:11,473 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invo
ke(DelegatingMethodAccessorImpl.java:25)
17:55:11,473 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:3


These are my properties:

java.util.Properties prps = new java.util.Properties();
prps.setProperty("cocosource.name","thought.CocoBase.CocoPowderPlugin20");
prps.setProperty("cocosource.jdbcdriver","oracle.jdbc.driver.OracleDriver");
prps.setProperty("cocosource.url","jdbc:oracle:thin:@127.0.0.1:1521:database:cocorep=resource:/CocoBaseRepository.xml:cocoprop=dynamic.querying=true,preserve.statements=true,useScrollableCursor=true");
prps.setProperty("cocosource.user","test");
prps.setProperty("cocosource.password","test");
prps.setProperty("cocosource.navmodel","classes_Model");
prps.setProperty("cocosource.debug", "true");

I didn't get this exception before, using the old cocosource.name, so it might be related.

Any thoughts?

06-21-2004 01:59 PM
Click Here to See the Profile for joan_caffe    Find more posts by joan_caffe        Edit/Delete Message    Reply w/Quote    IP: Logged
admin
Administrator

Registered: Apr 2001
Posts: 19
RE: OutOfMemory on EJB-QL query

Hi,

It looks like the cocoprop= entries in your url are not being set somehow. Can you set debug level to 5 (before invoking connect()) and send us the complete trace along with your map? If you can, send us also the complete code where you connect to the facade (i.e. your Service class) so we can review it. Please attach your files to a message to support@thoughtinc.com.

Thanks,
THOUGHT Support

06-21-2004 02:24 PM
Click Here to See the Profile for admin    Find more posts by admin        Edit/Delete Message    Reply w/Quote    IP: Logged
admin
Administrator

Registered: Apr 2001
Posts: 19

Hi,

We had a look at your log and we think we have found out what is going on. First, the query is being executed correctly. The ejb-ql query selects the following:

line 605:
2004-06-20 23:08:13,977 INFO [STDOUT] CocoPowder:: New Object being instantiated - Props = {F@CBQ@PHONE=1, F@CBQ@FATHER_NAME=Paulo, F@CBQ@EMAIL=Paulo, F@CBQ@GENDER_V_O_ID=1, F@CBQ@CNS_CODE=12345,
F@CBQ@ID=1, F@CBQ@NAME=John Cardoso, F@CBQ@STARTED_DATE=2004-12-30,
F@CBQ@CONTACT=CONTATO DO CASTOR FUNCIONANDO 10 1 1 1,
F@CBQ@MOTHER_NAME=Maria}

line 621:
2004-06-20 23:08:13,988 INFO [STDOUT] CocoPowder:: New Object being instantiated - Props = {F@CBQ@PHONE=1, F@CBQ@FATHER_NAME=Paulo, F@CBQ@EMAIL=luiz@teste.com, F@CBQ@GENDER_V_O_ID=1, F@CBQ@ID=2,
F@CBQ@CNS_CODE=12345, F@CBQ@NAME=John Cardoso, F@CBQ@CONTACT=Paulo 2 2 2 2 2, F@CBQ@MOTHER_NAME=Maria}

line 637:
2004-06-20 23:08:13,998 INFO [STDOUT] CocoPowder:: New Object being instantiated - Props = {F@CBQ@PHONE=1, F@CBQ@FATHER_NAME=Paulo, F@CBQ@EMAIL=luiz@teste.com, F@CBQ@GENDER_V_O_ID=1, F@CBQ@ID=3,
F@CBQ@CNS_CODE=12345, F@CBQ@NAME=John Cardoso, F@CBQ@CONTACT=Maria 3 3 3 3 3, F@CBQ@MOTHER_NAME=Maria}

line 653:
2004-06-20 23:08:14,078 INFO [STDOUT] CocoPowder:: New Object being instantiated - Props = {F@CBQ@PHONE=1, F@CBQ@FATHER_NAME=Paulo, F@CBQ@EMAIL=luiz@teste.com, F@CBQ@GENDER_V_O_ID=1, F@CBQ@ID=4, F@CBQ@CNS_CODE=12345, F@CBQ@NAME=John Cardoso, F@CBQ@CONTACT=Maria,
F@CBQ@MOTHER_NAME=Maria}

However, your navigation model has a link that connects PersonVO to GenderVO and vice-versa. Note that links are bidirectional. So, for instance, when then the gender of "John Cardoso" is loaded, it then tries to load all the PersonVO objects linked to that same gender
(i.e. GENDER_V_O_ID=1) so that closure is obtained for that object graph - as a consequence, the query at line 990 is executed:

2004-06-20 23:08:14,358 INFO [STDOUT] CocoPowder:: OP=<select> query = select
TB_PERSON.ID_PERSON_PK,TB_PERSON.NM_PERSON,TB_PERSON.CD_CNS,TB_PERSON.DT_BIRTH,TB_PERSON.NM_MOTHER,TB_PERSON.NM_FATHER,TB_PERSON.CD_PHONE,TB_PERSON.DS_CONTACT,TB_PERSON.NM_EMAIL,TB_PERSON.ID_GENDER_FK,TB_HEALTH_PROF.DT_STARTED from TB_PERSON , TB_HEALTH_PROF where TB_PERSON.ID_GENDER_FK = ? AND TB_PERSON.ID_PERSON_PK = TB_HEALTH_PROF.ID_PERSON_PK (+)

This will load all persons where TB_PERSON.ID_GENDER_FK = 1 and that's why you see other records such as

2004-06-20 23:08:14,598 INFO [STDOUT] CocoPowder:: New Object being instantiated - Props = {PHONE=12323, EMAIL=charles@teste, GENDER_V_O_ID=1, CNS_CODE=12345, ID=10, CONTACT=Antonio Santos, MOTHER_NAME=Maria Santos, NAME=Charles Marcus, FATHER_NAME=Pedro Santos}

at line 1216 being loaded. And this is correct - it is simply loading all the persons linked to that same gender. Does that make more sense now? To verify what we are saying, try commenting out the line where you specify your navigation model:

// prps.put("cocosource.navmodel","classes_Model");

This will leave your object graph withut any link mappings, and only the "root" PersonVO instances like 'John%' should be loaded. This is only so you can see that it is the link traversal from GenderVo to PersonVO which is causing other PersonVO instances to be loaded.

It is important to keep in mind that links are bidirectional. Now, If you don't want loading to occur from GenderVo to PersonVO, you can simply edit your link model and set "cascade load=false". This should fix your issue. Let us know how it goes.

Hope that helps!
THOUGHT Support

06-22-2004 06:36 AM
Click Here to See the Profile for admin    Find more posts by admin        Edit/Delete Message    Reply w/Quote    IP: Logged
All times are PST (US)    Post New Thread     Post A Reply
Forum Jump:
< Previous Thread     Next Thread >

Forum Rules:
Who Can Read The Forum? Any registered user or guest.
Who Can Post New Topics? Any registered user.
Who Can Post Replies? Any registered user.
Changes: Messages can be edited by their author. Messages can be deleted by their author.
Posts: HTML code is OFF. Smilies are OFF. vB code is OFF. [IMG] code is OFF.

Admin Options:
Open / Close Thread
Move Thread
Delete Thread
Edit Thread

< Contact Us - THOUGHT Inc. >

Copyright © Jelsoft Enterprises Limited 2000.
Copyright 2001 All Rights Reserved, THOUGHT Inc.