Hi Markus,
Thanks for looking into the caching. As you mentioned, since the spec does not
cover caching behavior, I probably should not depend on this behavior being
defined by the persistence provider. So it's best not to rely on caching, and
just try to minimize the number of queries that I make. It sounds like Marina's
suggestion might be a good way to do that.
Thanks for the info,
Tom
Markus Fuchs wrote:
> Hi Tom,
>
> Markus Fuchs wrote:
> > Hi Tom,
> >
> > I tested with TopLink-Essentials, which is the default JPA persistence
> > provider bundled with Glassfish. TopLink gets the results of the
> > Empoyee queries from the cache.
> >
> My apologies. I must have misinterpreted the log file...
> > Caching behavior is not prescribed by the spec. It highly depends on
> > the persistence provider, how many queries will be executed in your
> > situation.
> >
> > -- markus.
> >
> > Tom Mutdosch wrote:
> >> Hi Markus,
> >>
> >> Thanks for the reply. I know there's faster ways to get the data
> >> that I need, but if I did do it this way (n+1 queries) do you know
> >> if/how JPA caches this data? Once I queried for all of the
> >> Departments (containing their Employees), when I executed a separate
> >> query to get the filtered set of Employees for each Department
> >> object, would it go to the Database each time?
> Yes. TopLink does execute a query against the database again. But unless
> you specify the employeeCollection to be fetched eagerly, the query
> retrieving the Departments should not populate it. Then execute a query
> for the specific Employees belonging to each Department and having more
> than 15 years of service, which leaves you with n + 1 queries after all.
>
> Or following Marina's suggestion, sort the Employees by Department in
> memory.
>
> -- markus.