Wonseok,
This article also covers cache related configuration in TopLink
http://www.oracle.com/technology/tech/java/newsletter/articles/toplink/toplink_caching_locking.html
-Gordon
-----Original Message-----
From: Wonseok Kim [mailto:guruwons_at_gmail.com]
Sent: Tuesday, August 29, 2006 11:21 PM
To: persistence_at_glassfish.dev.java.net
Subject: Re: Disable TopLink caching
Hi, Gordon
Could you explain NONE and Weak cache type in detail?
Your prior exaplanation is different from my understanding of below reference.
http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html#TopLinkCaching
When I made a simple test, I could get fresh result from database with NONE option, but I couldn't get fresh one with Weak option. So I'm doubtful that Weak option gurantees no caching.
[sample test]
//EntityManager is closed and recreated between transactions
//create
begin();
Long id;
Employee e = bean.createEmployee("Mike1", "Old");
id = e.getId();
commitAndClose();
//let's update through JDBC
Statement stmt = connection.createStatement();
stmt.executeUpdate("UPDATE EMP SET address = 'New' WHERE EMPID = " + id);
stmt.close();
begin();
Employee e2 = em.find(Employee.class, id);
assertNotNull(e2);
String address2 = e2.getAddress();
println("address2 = " + address2);
commitAndClose();
begin();
Employee e3 = (Employee) em.createQuery("SELECT e FROM Employee e WHERE e.id = :id")
.setParameter("id", id).getSingleResult();
assertNotNull(e3);
String address3 = e3.getAddress();
println("address3 = " + address3);
commitAndClose();
[result]
1. toplink.cache.type.default="None"
### address2 = New
### address3 = New
2. toplink.cache.type.default="Weak"
### address2 = Old
### address3 = Old
With Weak what I got is "Old" addresses and find() does not even trigger SELECT statement.(same behaviour as default "SoftWeak" option)
One more thing: Why NONE is not recommended? Could you explain in detail when it can be dangerous?
-Wonseok
On 8/30/06, Gordon Yorke < gordon.yorke_at_oracle.com> wrote:
Marina,
WEAK guarantees no caching. Objects may, at any time, still be loaded within the VM and reading threads may still find these objects but TopLink is not actively caching the values.
Users who remove records between test runs will get the expected behaviour from WEAK.
--Gordon
-----Original Message-----
From: Marina.Vatkina_at_Sun.COM [mailto:Marina.Vatkina_at_Sun.COM]On Behalf Of
Marina Vatkina
Sent: Tuesday, August 29, 2006 1:13 PM
To: persistence_at_glassfish.dev.java.net
Subject: Re: Disable TopLink caching
Hello Gordon,
Does WEAK guarantee no caching between transactions or the cache will use
weak references and depending on GC cycles, the object might be in or out
of the cache?
The users are usually in a testing mode when they need this behavior, so
they exactly know what is there in the database. And in most cases, they
delete records from the database manually between the runs of the application.
thanks,
-marina
Gordon Yorke wrote:
> Hello all,
> Cache Type default of NONE should almost never be used (there are a few cases where object have no relationships where it can be used). Instead, for those users who wish to have no TopLink caching between transactions the default Cache Type should be set to WEAK.
> As an aside, eliminating caching almost never provides users with the behaviour they envision. In a concurrent system the view a user has (managed objects) of the volatile data can not reliably be expected to be 'the database has', that's the whole reason behind developing a locking strategy.
> Also, try-catch blocks are required around each refresh call *independent* of the caching type. Unless, the user knows that the object being refreshed can never be deleted.
> --Gordon
>
> -----Original Message-----
> From: Marina.Vatkina_at_Sun.COM [mailto:Marina.Vatkina_at_Sun.COM]On Behalf Of
> Marina Vatkina
> Sent: Monday, August 28, 2006 9:54 PM
> To: persistence_at_glassfish.dev.java.net
> Subject: Re: Disable TopLink caching
>
>
> Tom,
>
> The question is (I think - Markus is on vacation this week) whether
> it's possible to disable caching between transactions, so that the
> users see the world exactly as the database does. Otherwise the user
> will need to have a try-catch block around each refresh - not an EOU
> case. :(.
>
> thanks,
> -marina
>
> Tom Ware wrote On 08/24/06 07:20,:
>
>>There is a bunch of information on extend persistence context and
>>transaction scoped persistence context in section 5.6 of the
>>specification. I believe extended persistence context is the default.
>>
>>In a transactional persistence context, the ServerSession cache
>>implements any caching used between transactions.
>>
>>In an extended persistence context, the RepeatableWriteUnitOfWork is
>>used. As a result, in an extended persistence context, you must use the
>>UnitOfWork's built-in caching which by design uses FullIdentityMap in
>>order to ensure object identity is maintained throughout its use.
>>
>>-Tom
>>
>>Markus Fuchs wrote:
>>
>>
>>
>>>Hi Tom,
>>>
>>>How can a non-extended persistence context be specified in JPA? I
>>>understand your answer that toplink.cache.type.default can be used to
>>>achieve this goal as it applies to the ServerSession cache, which
>>>implements the caching btw. transactions functionality, correct?
>>>
>>>Thanks,
>>>
>>>-- markus.
>>>
>>>Tom Ware wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Hi Markus,
>>>>
>>>>In JPA, when using an extended persistence context we will cache
>>>>between transactions.
>>>>
>>>>The toplink.cache.type.default property affects the caching of the
>>>>TopLink ServerSession that underlies the EntityManagerFactory.
>>>>EntityManager's using an extended persistence context will be based on
>>>>a TopLink UnitOfWork which, in order to maintain object identity, has
>>>>a more complete cache.
>>>>
>>>>-Tom
>>>>
>>>>Markus Fuchs wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi Tom,
>>>>>
>>>>>Is it possible to disable TopLink's between transactions cache by
>>>>>setting
>>>>>
>>>>><property name="toplink.cache.type.default" value="NONE"/>
>>>>>
>>>>>in persistence.xml ?
>>>>>
>>>>>Thanks,
>>>>>
>>>>>-- markus.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>