Maybe implement a RemoteCollection and let the returned collection wrap a
remote collection.
This server has de opportunity to send a bunch of ejb's a
time
the same why as an ArrayList which dynamicly decrease size.
The RemoteCollection loads when needed the extra remote objects and drop
them on a overload.
the objects can be loaded with their index posistion
is this against the specs?
This is a crazy idea but in some situations this wil be a sollution to a
given problem.
but on the other side this problem should be solved by the facade pattern (A
Session Bean that delegates Entity operations).
Where the SessionBean does one request and returns an amouth of objects to
the clients on he's request
Tbone
----- Original Message -----
From: "Dmitri Colebatch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 24, 2001 5:10 PM
Subject: Re: [JBoss-dev] EJB/QL - JBoss extentions
> 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
