[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipselink-users] The ScrollableCursor's issues
|
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.