understanting GC live cycle of object(statemanager first level cache)

[killbulle <ma...@gmail.com>]

Hi, the list
i have a little question about the live cycle of object in open JPA 1.2.1
as i look the code i understand this:
->the root is the persistent object
->then you use a statemanager to manage state ;) and also as a key in  the
weak reference Map(ManagedCache or fist level cache)
->so if we dereference the persistent object , the object is GCed and the
disapear from the first level cache (as state manager is not root
referenced)
Is this correct ?
i ask this question to better  why agressive flushing(setTrackChangesByType)
just touch to second level cache.
Regards marc

-- 
View this message in context: http://openjpa.208410.n2.nabble.com/understanting-GC-live-cycle-of-object-statemanager-first-level-cache-tp5541894p5541894.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: understanting GC live cycle of object(statemanager first level cache)

[killbulle <ma...@gmail.com>]

Softreference, you right ! And then i understand more the jvm behavior with
jstat -gc...on some server, soft reference are hard to track on production
metric.
And then i need to investigate how to estimate their retention...
You help me a lot 
Thanks rick 

I definitly need to stop reading code too late or stop beer:)
-- 
View this message in context: http://openjpa.208410.n2.nabble.com/understanting-GC-live-cycle-of-object-statemanager-first-level-cache-tp5541894p5543831.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: understanting GC live cycle of object(statemanager first level cache)

[killbulle <ma...@gmail.com>]

Marc -

> ->so if we dereference the persistent object , the object is GCed and the
disapear from the first level cache (as state manager is not root
No. An entity will in the L1 cache until the context ends or it is
cleared(em.clear) or if the JVM is running low on memory(the managedcache
uses SoftReferences)...and I'm sure there are some other scenarios that
aren't coming to my head.

yes Soft reference sorry so it dispears  on memory pressure  !

in fact my question coming from the fact that i try to understand the best
approach for batch job and flushing strategy


This property has nothing to do with the L1 cache. 
Yes it seem to just flush more agressively

Thanks
Rick 
-- 
View this message in context: http://openjpa.208410.n2.nabble.com/understanting-GC-live-cycle-of-object-statemanager-first-level-cache-tp5541894p5543039.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: understanting GC live cycle of object(statemanager first level cache)

[Rick Curtis <cu...@gmail.com>]

Marc -

> ->so if we dereference the persistent object , the object is GCed and the
disapear from the first level cache (as state manager is not root
No. An entity will in the L1 cache until the context ends or it is
cleared(em.clear) or if the JVM is running low on memory(the managedcache
uses SoftReferences)...and I'm sure there are some other scenarios that
aren't coming to my head.


> why agressive flushing(setTrackChangesByType) just touch to second level
cache.
I've never looked at that property before this morning... but as far as I
can tell this property can be used to avoid putting data into the L2 cache.
This property has nothing to do with the L1 cache.

HTH,
Rick