Skip to main content

[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


Back to the top