hey list,
I'm not sure where to start with this, as I haven't contributed anything
(yet), but spent last weekend on something that I think is (partially)
relevant here. I wasn't going to post this message until next weekend
when I should have some time to clean some of my work up, but...
If someone is iterating over 1 million records, then using EJBObjects is
not going to work - yes? Either you'd use ejbSelect methods, or direct
JDBC if its read only. The problem with the latter is that no one wants
to write their own JDBC, thats what CMP is for...
anyway, what I've done is created a new bunch of container implemented
entity home methods, which I've called queryByFoo, but could be called
anything.
What I've done is change the EntityContainer so that home methods
beginning with queryBy are implemented in a similar way to findBy
methods. So for each findByFoo method you declare, you get a free
queryByFoo method that returns data object copies of your
entity. The code is a blend between the load and finder JDBC commands,
with the select coming from load and where coming from the finder. The
user only needs to specify a data object which has the same interface as
the abstract bean (regarding set/get methods).
I'm not sure how this will be received, but I think its very nice
functionality to be able to offer. I also think that it doesn't break the
spec (unless someone wants to implement their own home methods called
queryByFoo - but that can be handled in a number of ways).
This code doesn't have any read ahead in it as it returns a whole
collection, so its not relevant in that regard, but I think if someone is
paging in that volume, they're likely to be not changing anything...
I'd love to hear from ppl as to if this is good/bad/just plain stupid or
whatever... I'm hoping that next week some time I'll be able to post
patches...
cheesr
dim
On Mon, 24 Sep 2001, Dave Smith wrote:
>
>
> Oleg Nitz wrote:
>
> > Dave Smith wrote:
> >
> >>Keep the result set open, retieve from the set as necessary, probably
> >>using a cursor. That way if someone is doing a search that has 1 million
> >>records and after I display the first 10 and the client chooses the 3rd
> >>one, we have only created 10 objects.
> >>
> > No, no, no! We can't keep the result set open!
> > 1) having open result set and open Connection for each client,
> > we'll end up with too many open connections and too many open result
> > sets (256 open cursors by default in Oracle).
>
>
> Well then use limit and offset, but a cursor will be more efficient. I
> think what you have done is fine as the default case, so I see this
> fuctionality as an *option* not the default. Currently it is only doing
> searches that I would want this functionallity not anywhere else.
>
> > 2) How about transaction bounds? Can you keep cursor open after
> > transaction ends? I don't think so.
> >
>
> As stated previously this case has to be read-only, and would have to
> live within it's own transaction, or you are stuck with limit and offset.
>
>
>
>
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
