Re: [eclipselink-users] J2SE Caching Strategy?

["Tim Hollosy" <hollosyt@xxxxxxxxx>]

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