Re: [eclipselink-users] J2SE Caching Strategy?

["Tim Hollosy" <hollosyt@xxxxxxxxx>]

Nevermind Shaun, I found it: eclipselink.cache.shared.default=false at

 http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_(ELUG)#How_to_Use_the_.40Cache_Annotation

I'll let everyone know if this works since it will be a pretty common use case.

On Mon, May 12, 2008 at 2:55 PM, Tim Hollosy <hollosyt@xxxxxxxxx> wrote:
> Shaun,
>  That sounds like it will work great. Is there a way to set the
>  isolation level at the project level and override on an entity basis?
>  The wiki docs just show how to config it with the toplink workbench.
>
>  Thanks
>
>
>
>  On Mon, May 12, 2008 at 2:50 PM, Shaun Smith <shaun.smith@xxxxxxxxxx> wrote:
>  >
>  >  Hi Tim,
>  >
>  >  Sounds like you should set caches for non-reference data to "isolated".
>  > Instances of classes who's caches are isolated are not cached in the L2
>  > cache.   Once an EM is closed, objects who's classes are isolated can be
>  > GC'd.  I think this will get you the behavior you want.  Here's how the docs
>  > describe isolate caching:
>  >
>  >
>  > Isolated Client Session Cache
>  >
>  >
>  > This method always goes to the database for the initial read operation of an
>  > object whose descriptor is configured as isolated. By avoiding the shared
>  > session cache, you do not need to use the more complicated descriptor and
>  > query APIs to disable cache hits or always refresh. For more information
>  > about isolated client sessions, see Isolated Client Sessions. This is
>  > particularly useful for achieving serializable transaction isolation (see
>  > What You May Need to Know About Serializable Read Levels)
>  >
>  >
>  > There are some restrictions on relationships between isolated and shared
>  > classes.  Isolated classes can have relationships to shared classes but not
>  > vice versa.  This works fine when all your shared objects are reference
>  > data.
>  >
>  >
>  > Does this sound like it'll work for you?
>  >
>  >
>  >     Shaun
>  >
>  >
>  >
>  >  Tim Hollosy wrote:
>  >  Shaun, we are in a client server situation:
>  >
>  > ~50 RCP apps hitting the same database independently ,so they would
>  > all technically be "third parties" changing the database behind the
>  > scene, since each client is it's own seperate machine and doesn't
>  > share an L2 cache. So really we need to hit the database 99% of the
>  > time, the 1% of the time we want to hit the cache would be things like
>  > a list of states pulled from the database to populate a drop down
>  > list. There's no need to hit that every time, but all the other data
>  > is quite volatile.
>  >
>  >
>  > I think I confused you by talking about multiple EM's, really it
>  > doesn't matter, since the root of the problem is every client is
>  > independent and doesn't share a cache, which would be a common problem
>  > in most J2SE desktop apps.
>  >
>  > Hopefull that clears it up :)
>  >
>  > Thanks,
>  > Tim
>  >
>  >
>  >
>  >
>  > On Mon, May 12, 2008 at 1:40 PM, Shaun Smith <shaun.smith@xxxxxxxxxx> wrote:
>  >
>  >
>  >  Hi Tim,
>  >
>  >  Can you clarify your issues/goals before we get into how best to solve
>  > them?
>  >
>  >  So you don't want the EM-2 to see changes committed by EM-1? Reading from
>  > the database will just get you the same answer as you'll get from the L2
>  >  cache unless you have third parties modifying the database behind the
>  > scenes. Is this the root problem you're trying to combat?
>  >
>  >  Shaun
>  >
>  >
>  >
>  >
>  >
>  > --
>  >
>  >
>  >
>  >  Shaun Smith | Principal Product Manager, TopLink | +1.905.502.3094
>  >  Oracle Fusion Middleware
>  >  110 Matheson Boulevard West, Suite 100
>  >  Mississauga, Ontario, Canada L5R 3P4
>  >
>
> > _______________________________________________
>  >  eclipselink-users mailing list
>  >  eclipselink-users@xxxxxxxxxxx
>  >  https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>  >
>  >
>
>
>
>  --
>  ./tch
>



-- 
./tch