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

[dmitryerkin <dmitryerkin@xxxxxxxxxxxxx>]

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 an
allocation of 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-tp19392081p19526184.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.