On Tue, 25 Sep 2001, Philip Van Bogaert wrote:
> 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.
I would argue against BMP - at least CMP gives the container a chance to
optimize things through controlling
> 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.
isn't that the container's job? caching data?
anyway - I haven't heard much else on this, so I'll wait till I've got
something ready before saying any more. If anyone does have any thoughts
about my suggestion and how I should implement certain areas of it I'd be
keen to hear them.
At the moment I'm pondering how to handle relationships. Do I go the
adventurous road of loading the related bean - what about the related
bean's related beans? Or do I (what I think I'll do) just load the
primary key in and KISS? Anyway, will be in touch next week (o:
cheesr
dim
>
> 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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
