Re: [eclipselink-users] The ScrollableCursor's issues

[dmitryerkin <dmitryerkin@xxxxxxxxxxxxx>]

Hi, James Sutherland
Thank you again!

I implemented the finalize method for the class whose instances are
retrieved by the cursor and I can see the result of the finalizing in the
system log so I am sure that instances are collected.

@Override
protected void finalize() throws Throwable {
	// TODO Auto-generated method stub
	super.finalize();
	System.out.println("OebsView.finalize()");
	System.out.println("id=" + this.getId());	
}

And I use this code to tell the JVM to collect the garbage:

Runtime rt = Runtime.getRuntime();
rt.gc();

But I have the java.lang.OutOfMemoryError in the end.



Regards,
Dmitry




James Sutherland wrote:
> 
> In Java the VM will garbage collect whenever it feels it needs to.  There
> is an API on java.lang.System.gc(), but this is only a suggestion, the VM
> may still not perform a gc.
> 
> Ensure that nothing in your application is holding onto the objects.  If
> anything references an object, it cannot gc.  There are memory profilers
> such as JProfiler that can pinpoint memory leaks.  The easiest way to find
> out if an object has gc'd is to create a WeakReference to it, and check if
> the reference is null.
> 
> In general I would not recommend using NoIdentityMap, weak should be fine.
> 
> Are you running out of memory?  Did you try increasing your JVM's memory?
> 
> 
> dmitryerkin wrote:
>> 
>> Hi, James Sutherland
>> Thanks for your help and patience
>> 
>> The level of the cache which is configured for the descriptor of the
>> OebsView.class is None:
>> 
>> 	// ClassDescriptor Properties.
>> 	descriptor.useNoIdentityMap();
>> 	descriptor.setIdentityMapSize(0);
>> 	descriptor.useRemoteNoIdentityMap();
>> 	descriptor.setRemoteIdentityMapSize(0);
>> 	descriptor.setIsIsolated(true);
>> 	descriptor.setAlias("OebsView");
>> 
>> descriptor.setCacheSynchronizationType(ClassDescriptor.DO_NOT_SEND_CHANGES);
>> 
>> I added the dontMaintainCache() but it did not change anything in the
>> allocation of the jvm's memory:
>> 
>> 	ReadAllQuery queryByTime = new ReadAllQuery(OebsView.class, where);
>> 	queryByTime.useScrollableCursor();
>> 	queryByTime.setIsReadOnly(true);
>> 	queryByTime.dontMaintainCache();
>> 		
>> 	ut.setTransactionTimeout(60*60*24);
>> 	ut.begin();
>> 		
>> 	jpaEM = org.eclipse.persistence.jpa.JpaHelper.getEntityManager(em);
>> 	uow = jpaEM.getActiveSession().getActiveUnitOfWork();
>> 	if(uow == null){
>>     		System.out.println("uow is null");    		
>>     		uow = jpaEM.getActiveSession().acquireUnitOfWork();
>> 	}		
>> 	cursorByTimeAndOrganizationId = (ScrollableCursor)
>> uow.executeQuery(queryByTime);
>> 
>> 
>> The memory is still allocated after the transaction is committed.
>> Is this a jvm's feature? Can I use a jvm's interface to release memory?
>> 
>> 
>> Regards,
>> Dmitry
>> 
>> 
>> 
>> James Sutherland wrote:
>>> 
>>> The objects will no longer be held by the UnitOfWork/EntityManager, but
>>> will still be in the cache.  Depending on what caching you are using,
>>> they will eventually garbage collect (weak references).  SoftWeak is the
>>> default cache type, which will hold 100 objects using soft reference and
>>> the rest using weak references, weak will garbage collect in the next
>>> gc, and soft will garbage collect when memory is low.  You can change
>>> your cache type to weak to allow better garbage collection.  You could
>>> potentially also set dontMaintainCache() on the query to avoid the cache
>>> entirely.
>>> 
>>> If you set read-only on the query, you don't need to execute it with the
>>> Session, using the EntityManager is fine.
>>> 
>>> 
>>> 
>>> dmitryerkin wrote:
>>>> 
>>>> Hi, James Sutherland!
>>>> Thanks a lot for your help.
>>>> 
>>>> One your tip helped me but another did not help.
>>>> I found settings for the transaction service and changed the value of
>>>> timeout. It works.
>>>> But a memory for the previous block is not released after the next
>>>> block is getted although I changed my code:
>>>> 
>>>> 	ReadAllQuery queryByTime = new ReadAllQuery(OebsView.class, where);
>>>> 	queryByTime.useScrollableCursor();
>>>> 	queryByTime.setIsReadOnly(true);
>>>> 	
>>>> 	ut.setTransactionTimeout(60*60*24);
>>>> 	ut.begin();
>>>> 		
>>>> 	jpaEM = org.eclipse.persistence.jpa.JpaHelper.getEntityManager(em);
>>>> 	uow = jpaEM.getActiveSession().getActiveUnitOfWork();
>>>> 	if(uow == null){
>>>>  		System.out.println("uow is null");    		
>>>>     		uow = jpaEM.getActiveSession().acquireUnitOfWork();
>>>> 	}		
>>>> 	cursorByTimeAndOrganizationId = (ScrollableCursor)
>>>> uow.getParent().executeQuery(queryByTime);
>>>> 
>>>> 
>>>> I could not try the third way which You advised because I could not
>>>> find the class where the clear() method is declared.
>>>> 
>>>> 
>>>> Regards,
>>>> Dmitry
>>>> 
>>>> 
>>>> 
>>>> James Sutherland wrote:
>>>>> 
>>>>> You are executing the query in the UnitOfWork so all of the returned
>>>>> objects will be managed (and not allowed to garbage collect).  If you
>>>>> execute it in the Session (uow.getParent()), then the objects will not
>>>>> be managed and free to gc, (but must be used as read-only).  You could
>>>>> also call clear() in between each page, or set the query to be
>>>>> read-only (setIsReadOnly(true) same as exec in session).
>>>>> 
>>>>> The rollback seems like it is cause because you have a transaction
>>>>> timeout set somewhere in WAS or your DB.  You will need to find and
>>>>> increase this timeout.
>>>>> 
>>>>> You could also potentially use JPA firstResult/maxResult to page the
>>>>> results.
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/The-ScrollableCursor%27s-issues-tp19392081p19550791.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.