Hello Wonseok,
toplink.cache.shared.default=false really should not be recommended except in certain circumstances. In most cases users will benefit from a cache. Setting the per entity value would be a better approach.
The cache type still applies to the EntityManager as the PersistenceContexts can be cleared but the backing IdentityMap (or cache) still exists for that EntityManager. The importance of the setting is reduced but will still need to be considered in some cases.
--Gordon
-----Original Message-----
From: Wonseok Kim [mailto:guruwons_at_gmail.com]
Sent: Thursday, August 31, 2006 9:32 AM
To: persistence_at_glassfish.dev.java.net
Subject: Re: TopLink Cluster Documentation
Hi, Doug
Thanks for clarifying this.
Some questions...
If toplink.cache.shared.default=false become to work as expected, can we recommend this option for users who want to disable caching between transactions instead of toplink.cache.type.default=NONE?
Also I would like to know what toplink.cache.type.x option mean if toplink.cache.shared.x is false?
Does the cache type apply to the identiy maps of isolated client sessions? I guess the cache type is meaningless for isolated client session in JPA, because client session goes away when persistence context(or EntityManager) is closed. While persistence context is alive it caches working sets, so isolated client session cache seems to have no effect. Is this right?
- Wonseok
On 8/31/06, Doug Clarke <douglas.clarke_at_oracle.com> wrote:
Marina,
Configuring isolated caching at EntityManager level with toplink.cache.shared.X = FALSE does prevent caching across entity managers and thus transactions if you acquire a new one per transaction.
The intent of this functionality was originally to support database security technologies where each connected user could see a different set of rows based on database filters (Oracle VPD/OLS). It also works well for highly volatile entity types where caching across entity managers is less useful and you would need to refresh from the database in each entity manager anyways.
Ideally users would configure this on a per entity types basis but the default configuration can also be used if more types are volatile then not. It is important to note that you cannot have relationships from entity types in the shared cache to those in the isolated ones.
I am currently investigating a bug with toplink.cache.shared.default but have verified that toplink.cache.shared.<ENTITY> works as expected.
Doug Clarke
Principal Product Manager
Oracle TopLink
douglas.clarke_at_oracle.com
-----Original Message-----
From: Marina.Vatkina_at_Sun.COM [mailto: Marina.Vatkina_at_Sun.COM]On Behalf Of
Marina Vatkina
Sent: Wednesday, August 30, 2006 5:20 PM
To: persistence_at_glassfish.dev.java.net
Subject: Re: TopLink Cluster Documentation
Doug,
Do you mean that setting toplink.cache.shared.default to false
completely disables caching between transactions, if each transaction
is executed in its own entity manager? (This is a question being
discussed on another thread in the last 2 days).
thanks,
-marina
Doug Clarke wrote On 08/30/06 08:47,:
> Peter,
>
> TopLink's default caching is to cache entities in its shared cache, container within the server session. This shared cache spans entity managers and transactions.
>
> As shown in table 1-2 of Tom's second link there are two persistence unit properties of interest:
>
> toplink.cache.shared.default - the default caching used for all entity types. Setting this to false will put you in a cache per EntityManager (client session) with no sharing between clients.
>
> toplink.cache.shared.<ENTITY> - allows you to use a different setting per entity type then the default.
>
> Cheers,
>
> Doug
>
> -----Original Message-----
> From: Peter Havelaar [mailto: peter-java_net_at_jabbah.net]
> Sent: Wednesday, August 30, 2006 11:34 AM
> To: persistence_at_glassfish.dev.java.net
> Subject: Re: Toplink Cluster Documentation
>
>
> Thank you Tom,
>
> I see when persisting an object it gets written to the session cache of the
> parent server.
> How do you configure Toplink to have a session server and clients?
>
> Regards,
> Peter
>
> ----- Original Message -----
> From: "Tom Ware" <tom.ware_at_oracle.com>
> To: < persistence_at_glassfish.dev.java.net>
> Sent: Wednesday, August 30, 2006 3:56 PM
> Subject: Re: Toplink Cluster Documentation
>
>
> Hi Peter,
>
> TopLink Essentials does not currently include any specific clustering
> support. Its caching functions in a cluster through effective configuration
> of optimistic locking, cache type/size, and query refreshing.
>
> Here is a good article describing the core locking/caching functionality of
> TopLink -
> http://www.oracle.com/technology/tech/java/newsletter/articles/toplink/toplink_caching_locking.html
>
> For details of how to configure TopLink Essential's caching see -
> http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html#TopLinkCaching
>
>
> -Tom
>
> Peter Havelaar wrote:
>
>
>>Hello guys,
>>
>>I have been trying to find the documentation of how to setup a cluster
>>configuration with Toplink JPA in glassfish.
>>Can anyone point me in the right direction?
>>And how does Toplink's cluster capabilities integrate with Glassfish's
>>V2 new cluster abilities.
>>
>>Regards,
>>Peter Havelaar
>
>
--
Wonseok Kim
Senior Developer, TmaxSoft