The problem with EJB2.0 relationships that it's really hard to configurate
it.
But yes Entity should support n- depth relationships
The recursive hole is also a problem (We had that with a MOF Inspector)
Applications can catch this, I personally think that it will cause some
problems.
Just think about it how many people use EJB's direct in jsp
if someone wants to display a full three structure of an EJB and he forget
to check that he already has displayed a bean.
that wil hang forever thus a max depth can be a nice feature where -1 is
unlimmited
Wat is current entity-relationship implementation of jboss alpha ?
Tbone,
---- Original Message -----
From: "Dmitri Colebatch" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 25, 2001 11:34 PM
Subject: Re: [JBoss-dev] EJB/QL - JBoss extentions
> 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
