Thanks Doug for your kind pointing out,
I modified contents in Session Cache, Disabling shared sesion cache and some
other sections as you commented.
Please comment if there is still something strange.
In regard to issue 1054, EM.clear() behaves differently whether there is a
tx or not. If there is no tx, it nullify active UnifOfWork field so isolated
cache goes away too. But if EM.clear() is called inside tx, it just clears
UnitOfWork. Is it intended? or Did you file the issue to modify this
behavior?
public void clear(){
if (this.isExtended()){
if (this.extendedPersistenceContext != null) {
if (checkForTransaction(false) != null){
this.extendedPersistenceContext.clear();
}else{
this.extendedPersistenceContext = null;
}
}
} else {
transaction.clear();
}
}
Thanks
- Wonseok
On 9/8/06, Doug Clarke <douglas.clarke_at_oracle.com> wrote:
>
> Wonseok Kim,
>
> Thanks for putting this out there. I has it on my to-do list as it is
> important information and can be confusing to new users. Overall it is good
> and reads well. The following are just some minor comments.
>
> - I know it is somewhat confusing with client session and server
> sessions both having a cache. To make things more clear I tend to avoid
> saying 'session cache' as it is not always clear which one you mean. As an
> example I would re-name your section "Disabling session cache" to be
> something like "Disabling Shared Cache" or "Disabling L2 Cache"
>
> Isolated cache == client session cache
>
> Shared cache = server session cache (L2)
> - Bug 1054<https://glassfish.dev.java.net/issues/show_bug.cgi?id=1054>:
> EM.clear() does not clear entities cached in the client session's
> isolated cache. It does clear the EM's associated UnitOfWork used to manage
> the persistence context tracking any changes made. This means that after a
> clear if you are using isolated caching the next find for an already cached
> entity will not go to the database as expected.
> - Cache hits on the isolated (client) or shared server session
> caches which completely avoid a database call are only for em.findcalls. All queries will go to the database and then when processing results
> the session caches will be used to avoid re-building entities that are
> already cached (still an important performance gain). This explains what you
> are seeing in the THIRD transaction of your section: *"If there are
> external changes...?". *
>
> Your blog mentions that you will get a cache hit but does not make
> it clear that is currently only for finds.
>
> As far as the additional functionality concerning caching features in
> Oracle TopLink that do not yet exist in TopLink Essentials we appreciate the
> feedback and are evaluating enhancement requests of this nature as we lay
> out our roadmap for this product. Please ensure that all of your requests
> have enhancement requests filed with detailed explanation of the customer
> need so that we can prioritize them appropriately.
>
> Doug Clarke
> Principal Product Manager
> Oracle TopLink
> douglas.clarke_at_oracle.com
>
> -----Original Message-----
> *From:* Wonseok Kim [mailto:guruwons_at_gmail.com]
> *Sent:* Thursday, September 07, 2006 11:51 PM
> *To:* persistence_at_glassfish.dev.java.net
> *Subject:* Blog about the cache of TopLink Essentials
>
> Hi, all
>
> I bloged about the cache of TopLink Essentials.
> http://weblogs.java.net/blog/guruwons/archive/2006/09/understanding_t.html
>
>
> Thanks for all members helping me understand the internal cache. If you
> see any incorrect one please comment on.
>
> --
> Wonseok Kim
> Senior Developer, TmaxSoft
>
>