Re: Proxy, Prefetching, Memory Usage

[Jakob Braeuchi]

hi andreas,
i just comitted a patch (OJB 1.1) to solve this problem. please have a 
look at it.

jakob
Andreas Bohnert schrieb:
hello jakob,
I just have choosen 'Article' as an example. I don't need to prefetch a 
relation from there.

This problem here is related with my posting:
Out of Memory on Large ResultSets/Needed: SetFetchSize Method.
I have a large table with some big columns. The PG jdbc driver loads the 
entire ResultSet all at once and keeps it in memory.

so, there a two issues:
- to minimize the memory consumption and to force the jdbc driver to use 
a cursor we would need a setFetchSize method (martin kalen has posted 
this already on the developer list)
- ojb could only select the pk's if the table is configured as a proxy. 
this second issue is not necessary anymore if we would have a 
setFetchSize, but it would be an improvement too.

regards,
andreas

Jakob Braeuchi wrote:
hi andreas,
i opened an issue in jira
http://issues.apache.org/jira/browse/OJB-22
jakob
Jakob Braeuchi schrieb:
hi andreas,
ojb selects all columns but creates proxies instead of fully 
materialized Article objects.
what related object do you want to prefetch here ?

jakob
Andreas Bohnert schrieb:
hi,
may someone can help me with the proxies, please!
everything works fine, prefetching works as it should, but when OJB 
initially selects the oid's, it does select all fields instead of 
just the pk!

let's say, there is a table 'Article' with 200 000 objects.
I have written an Article Class, an ArticleProxy and an 
ArticleInterface. The proxy is configured in the repository_user.xml 
like this:

<class-descriptor
 class="at.wb.Article"
 proxy="at.wb.ArticleProxy"  proxy-prefetching-limit="100"
 table="article"
>
 <field-descriptor id="0"
   name="articleId"
   column="articleId"
   jdbc-type="INTEGER"
   primarykey="true"
   autoincrement="true"
 />
 <field-descriptor id="4"
   name="data"                      <-- big!
   column="data"
   jdbc-type="VARBINARY"
 />
</class-descriptor>
When I select the Article table I use a CollectionByQuery.
       Criteria crit = new Criteria();
       crit.addEqualTo(...
       crit.addEqualTo(...
             QueryByCriteria q = new QueryByCriteria( Article.class, 
crit );
       q.addOrderBy("articleId", true);

       col = broker.getCollectionByQuery(query);
When I look at the sql statement, I can see, that OJB selects ALL 
fields (in this case articleId and data ) instead of just the 
primary key!
I get a huge memory usage because of this select, and it seems, that 
this is because of the 'data' field, which is very big.

to get around this, I select the oid's with a ReportQuery, and build 
the proxies like this:

       List oids = getReportQueryList(q);
       RemovalAwareCollection rows = new RemovalAwareCollection();
       for (Iterator it = oids.iterator(); it.hasNext(); ) {
           Object[] row = (Object[]) it.next();
           Integer oid = (Integer) row[0];
           rows.add( VirtualProxy.createProxy( broker.getPBKey(), 
ArticleProxy.class,
                   new Identity( Article.class, Article.class, row)  
));          }

this works fine, but the prefetching does not work anymore! when I 
access a getter, I get the data objects one by one.
what's wrong with this??

thanks for your help,
andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]