[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] J2SE Caching Strategy?
|
Thanks Shaun,
I'll keep an eye on the bugs, and that makes sense about the
difference between caches now :)
Tim
On Tue, May 13, 2008 at 5:06 PM, Shaun Smith <shaun.smith@xxxxxxxxxx> wrote:
>
> Hi Tim,
>
> I filed:
>
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=231934 Isolated Class
> Relationships Not Resolved Through Cache Hit
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=231843 Persistence.xml:
> cache.shared.default not treated like default
> based upon your comments.
>
> I do think the isolated cache configuration I suggested should work well
> for you as the it avoids placing objects into the shared cache so they only
> live as long as your EntityManager. This is how I'd expect a typical fat
> client in a 2-tier architecture to behave.
>
> Ideally I'd like to see a very clear way to turn off caching (all the
> time) and only use it on specific entities though, without any changes
> on how/when SQL is built.
>
> You have to careful when you say "turn off caching". :-) What you
> probably mean is turn off L2 caching. If you turn off caching altogether
> you sacrifice object identity as each time you need to resolve a
> relationship or query an object you will get a new copy. You may end up
> with many copies of the same object. This can be fine if you can afford the
> read cost and don't plan on making any changes as one copy is as good as the
> next for read only data.
>
> Shaun
>
>
>
>
> Thanks,
> Tim
>
> On Mon, May 12, 2008 at 5:33 PM, Shaun Smith <shaun.smith@xxxxxxxxxx> wrote:
>
>
> Oh and btw, you can also specify isolation for an Entity in the
> persistence.xml as a property. For example,
>
> <property name="eclipselink.cache.shared.default"
> value="false"/>
> <property name="eclipselink.cache.shared.Publisher"
> value="true"/>
> <property name="eclipselink.cache.shared.Title" value="true"/>
>
> Will get you what you're currently trying to do with
> @Cache(isolated=false,..) annotations.
>
> Another FYI, there's bug filed to switch to a more "positive" @Cache
> property and use "shared" instead of "isolated". This means at some point
> before 1.0 your @Cache annotations will require adjusting.
>
> Shaun
>
>
>
>
> Shaun Smith wrote:
> Hi Tim,
>
> I'm taking a look at the behavior you're seeing. I'll get back to you
> asap.
>
> Shaun
>
> Tim Hollosy 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
>
>
>
>
>
>
>
> --
>
>
>
> Shaun Smith | Principal Product Manager, TopLink | +1.905.502.3094
> Oracle Fusion Middleware
> 110 Matheson Boulevard West, Suite 100
> Mississauga, Ontario, Canada L5R 3P4
>
>
> --
>
>
>
> 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
>
>
>
>
>
>
>
>
> --
>
>
>
> 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
