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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>