Re: extending the life of a LRS query

[Craig L Russell]

Hi,




Craig

On Dec 11, 2006, at 5:35 PM, roger.keays wrote:

Note that not all databases support efficient FirstResult and MaxResults implementations. But even those that don't have built-in support for skipping "n" rows, the usual use case is to skip where n is small. The most frequent case is FirstResult == 0 followed in rapidly descending order n, 2*n, 3*n, and vanishingly small. And most databases will be reasonably efficient for these common cases.

Hi Patrick,

Thanks for your detailed reply.


Patrick Linskey wrote:

EM (either via a stateful session bean or via using a non-JTA entity

cautions about keeping database connections open across multiple
requests apply.

If what you're looking for is to hold the cursor to the DB open across multiple requests, you'll need to create an extended-persistence- context manager, obtained through an EMF), and then do the query in that EM and bind the query into session state somewhere. Of course, all the normal

I guess that was the obvious solution. I subscribed to the

works very well for me. I can bind my list to jsf dataTable and scroll

improved my quality of life :)

one-pm-per-request pattern so long ago that I've even forgotten why. This through the results as they're loaded from the database. I think you just

If you're just looking to page through results for a search-result- style listing, you might be interested in the JPA Query.setFirstResult() and

Query.setMaxResults() calls -- these allow for efficient (but

using range data in the query cache.

non-isolated) paging through queries. Don't forget to add an ordering to your query when you do this, of course. Oh, and OpenJPA is smart about

I tried this out also and it seems to be quite efficient (not all orm

OpenJPA is smart about ranges.

Cheers,

Roger

products are as good). Not as convenient as the LRS, but good to know that

-----Original Message-----
From: Dain Sundstrom [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 09, 2006 9:24 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: extending the life of a LRS query

I am by no means an OpenJPA expert, but I did see something related
to this when reading the docs yesterday.  OpenJPA has a
QueryResultsCache where it keeps the results of a query so if
you run
the query again you get the same results (I'm not sure if that is
what you want).  Here is the code from the docs:

OpenJPAEntityManagerFactory oemf = OpenJPAPersistence.cast(emf);
QueryResultCache qcache = oemf.getQueryResultCache();
EntityManager em = emf.createEntityManager();

Query pinQuery = em.createQuery(...).
     setParameter(0, paramVal0).
     setParameter(1, paramVal1);
qcache.pin(pinQuery);
Query unpinQuery = em.createQuery(...).
     setParameter(0, paramVal0).
     setParameter(1, paramVal1);
qcache.unpin(unpinQuery);


Hope that helped.

-dain

On Dec 8, 2006, at 8:04 PM, roger.keays wrote:

Hi,

I'm trying to use OpenJPA's fetch plan extensions to have a query
return a
large result set. It seems to work okay, except that the LRS gets
closed /
detached with the EntityManager, which only makes it useful

for one

request.
Is it possible to have the LRS stay open after the em has been
disposed?

Thanks,

Roger
--
View this message in context: http://www.nabble.com/extending-the-
life-of-a-LRS-query-tf2784490.html#a7769269
Sent from the open-jpa-dev mailing list archive at Nabble.com.

--

View this message in context: http://www.nabble.com/extending-the- life-of-a-LRS-query-tf2784490.html#a7825755

Sent from the open-jpa-dev mailing list archive at Nabble.com.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature