[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] J2SE Caching Strategy?
|
This is an old thread, so I thought I'd check in, with M10 we were
able to switch back to an isolated cache, this is working great, we're
not running into any extra SQL compared to running with a shared
cache. This we we can guarantee that all our fat clients are getting
fresh data all the time.
We've been running in production with about ~25-50 clients using
eclipselink (for about a month now) and haven't run into any major
issues yet.
Look for a blog post soon detailing our J2SE RCP Architecture, I
think it will be helpful to some people out there getting started.
It's a testament to the Eclipselink code that before the official 1.0
release we're able to run full production code with thousands of
transactions a day though.
/Tim
On Tue, May 13, 2008 at 5:57 PM, Tim Hollosy <hollosyt@xxxxxxxxx> wrote:
> 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
>
--
./tch
