You are so right,
I think if one want to use thousands of records he should not use CMP. he
should use BMP or use no Entities at all.
one could use them both entity beans and direct database access with jdbc
the remote collection idea of my maybe a cool one
but it isn't that pratical.
One could also use a seperate thread on the client or the webcontainer and
have a entity or database lookup every hour. the data should be transfered
to regular java objects or Javabeans.
Tbone,
----- Original Message -----
From: "Dmitri Colebatch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 25, 2001 1:43 AM
Subject: Re: [JBoss-dev] EJB/QL - JBoss extentions
> My idea is to not use remote objects _at all_ and just have data
> copies. There are many situations where entity ejbs are not appropriate,
> and a lot of them stem from a need to get a quick copy of a _lot_ of
> data. The key factors here are:
>
> - no need to modify the data
>
> - a desire to not lock the data, and acceptance of the possibility that
> it might be a little bit out of date (if there is a tx currently going on)
>
> I would also like to get it nice and clean without doing anything more
> complicated than required as a milestone.
>
> My test atm is an AccountBean, which has findLargeAccounts as a container
> implemented finder, and I'm testing queryLargeAccounts which returns a
> Collection of AccountData objects.
>
> I suppose that paging can be implemented on top of it without too much
> drama, just not at that stage yet.
>
> cheers,
> dim
>
> On Mon, 24 Sep 2001, Philip Van Bogaert wrote:
>
> > 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
> >
>
>
> _______________________________________________
> 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
