Hello Jon,
In TopLink Essentials the Persistence Context is different from the 'Cache'. A cache exists at the Persistence Unit level that is shared by all of the EntityManagers from that Persistence Unit. This cache reduces the number of trips made to the database. The Persistence Context is different than a cache. The Persistence Context contains those objects that are known to the persistence context (managed) and will be tracked for changes.
--Gordon
-----Original Message-----
From: Jon Miller [mailto:jemiller_at_uchicago.edu]
Sent: Tuesday, January 16, 2007 1:39 PM
To: persistence_at_glassfish.dev.java.net
Subject: Re: What criteria does TopLink use to 'cache' entities to
avoiding re-executing SQL to find an object?
I'm in the process of trying to figure this out too. I'm wondering if there
is documentation somewhere that explains how this works? The thing that is
confusing me a bit is the difference between a persistence context and the
cache. Intially, I was thinking they were the same, but now, I'm thinking
not. The EJB Persistence spec says that objects in the persistence context
are supposed to become detached when you close the EntityManager. This is
what's confusing me. In theory, they're getting evicted from the persistence
context, but, they remain in the cache?
Jon
----- Original Message -----
From: "Martin Bayly" <mbayly_at_telus.net>
To: <persistence_at_glassfish.dev.java.net>
Sent: Monday, January 15, 2007 2:43 PM
Subject: What criteria does TopLink use to 'cache' entities to avoiding
re-executing SQL to find an object?
> What criteria does TopLink use to determine that an existing cached
> instance of a required object can be re-used rather than executing an SQL
> query to load the object?
>
> I'm seeing output like this under one particular setup of my application
> code:
>
> [TopLink Finest]: 2007.01.15
> 12:01:01.515--UnitOfWork(9613092)--Thread(Thread[main,5,main])--Register
> the existing object com.toplink.test.MailRecipient_at_29
> [TopLink Finest]: 2007.01.15
> 12:01:01.515--UnitOfWork(9613092)--Thread(Thread[main,5,main])--Register
> the existing object com.toplink.test.MailMessage_at_91e90d7
> [TopLink Finest]: 2007.01.15
> 12:01:01.515--UnitOfWork(9613092)--Thread(Thread[main,5,main])--Register
> the existing object com.toplink.test.User_at_6a68de7
>
> This is good because it means it's not continuously hitting the database
> for data loaded by the same query or an earlier query. Does TopLink have
> a cache per EntityManagerFactory - I think I remember seeing a reference
> to this in an earlier post.
>
> This means that if I execute code like the following
> - create an EntityManager 1,
> - load an object User A, - here I see a query against the database
> - close the EntityManager 1,
> - open a new EntityManager 2 from the same factory,
> - request the object User A again
>
> ... I see one of the above messages and we don't hit the database again?
>
> However, in another setup of my application code, we are trying to use
> Spring JPA with TopLink Essentials. With Spring in the picture, it seems
> like I don't see the above type of message. Instead, we are continuously
> hitting the database even for a referenced object that is utilized by many
> rows in the result set of a single query. Actually, I see the above
> messages for data created and retrieved by the same EntityManagerFactory.
> But as soon as I close down the app, restart and hit the same data, it
> never loads from cache, no matter how many times we query for the data.
>
> e.g. querying mail messages for user 1. Each mail message has an embedded
> member User which should have value user1 for the results of the query.
> We see a query for user 1 being executed against the database for every
> mail message returned and this is killing performance. This is a general
> problem for all entities when using Spring JPA.
>
> Thanks for any insights you can give.
> I'm not saying this is a TopLink bug but it seems that the combination of
> TopLink and Spring JPA in a Java SE environment does not play nicely.
>
> Using Spring 2.0 and TopLink v2 b26.
> I've tried this with the latest build of TopLink (v2 b31) and get same
> problem.
>
> Cheers
> Martin
>