[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] The ScrollableCursor's issues
|
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.
>>>>
>>>
>>>
>>
>>
>
>
-----
---
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/
EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
--
View this message in context: http://www.nabble.com/The-ScrollableCursor%27s-issues-tp19392081p19535597.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.
