After reading through all the threads having to do with caching, I've
decided to simply link from the App Server Dev Guide to this section:
http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html#TopLinkCaching
June
Marina Vatkina wrote On 08/29/06 11:12 AM,:
> Great!
>
> June, can we make sure it's documented clearly? People are asking this
> over and over again.
>
> thanks,
> -marina
>
> Gordon Yorke 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>