[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] J2SE Caching Strategy?
|
The saga continues, I once again apologize for the brainspill :)
disableHits still uses the cache for identity, so doing a find still
stops at our friend the cache!
I ended up using the solution offered by Kim's blog, of doing a
refresh on my found object, this can be wrapped in a "freshFind"
method easily enough.
This will work for now, and I still may use disableHits so that uses
in a non em.find(...) context will still hit the DB.
Thanks for bearing with me :)
Tim
On Mon, May 12, 2008 at 4:00 PM, Tim Hollosy <hollosyt@xxxxxxxxx> wrote:
> Sorry to continue to make this thread harder to read than it has to,
> but I see I read the javadocs wrong.
>
> alwaysRefresh causes the *cache* to always be refreshed WHEN you hit the DB.
>
> disableHits causes the entity to skip cache hits and go directly to
> the databaase, unfortunately this doesn't appear to be working either
> though, so I'll keep huntin'.
>
>
>
> On Mon, May 12, 2008 at 3:48 PM, Tim Hollosy <hollosyt@xxxxxxxxx> wrote:
> > Well that didn't work as well as I thought it would. Number One, it
> > appears setting the defaults in the Persistence Unit Properties
> > overrides all @Cache Annotations ("Using this property, you can
> > override the @Cache annotation") -- this is backwards of the way I
> > thought it'd work. So I just decided to use the @Cache annotation on a
> > case by case basis - once I turned on isolated the relationships
> > started being funky and spit out a bunch of errors when setting it on
> > one base entity that had lots of children. And when isolated was on
> > globally that was even worse, causing way too many queries.
> >
> > I'm really kind of stumped why I can't just leave the caching
> > properties set as default on the PU, then use
> > @Cache(alwaysRefresh=true). It seems like this should work, but it
> > definitely doesn't. Really if this annotation worked, I'd be golden.
> > It looks like playing around with mixing isolated & shared just causes
> > problems in extraneous sql.
> >
> > So, I'm kind of back to square one unless someone has some insight to
> > the alwaysRefresh working in the @Cache annotation.
> >
> > Thanks
> >
> >
> >
> >
> > On Mon, May 12, 2008 at 3:04 PM, Tim Hollosy <hollosyt@xxxxxxxxx> wrote:
> > > 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
> > >
> >
> >
> >
> > --
> > ./tch
> >
>
>
>
> --
> ./tch
>
--
./tch
