Hello Juan,
What you are seeing is most likely people who have subscribed some time ago forgot
about it and now start receiving mail due to the fixed mail problem as of yesterday
(see other thread). Could that be it?
/Magnus Stenman, the Orion team
----- Original Message -----
From: "Juan Lorandi (Chile)" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Wednesday, March 21, 2001 1:01 AM
Subject: RE: Why Entity EJBs?
> somebody suscribed a whole lotta of criticalmass people to this list; can't
> we have a subscribe/unsubscribe confirmation??
>
> JP
>
> > -----Original Message-----
> > From: Carla Marcyniuk [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, March 20, 2001 5:53 PM
> > To: Orion-Interest
> > Subject: RE: Why Entity EJBs?
> >
> >
> > Please take me off this list as I have no interest in this
> > conversation.
> >
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Juan Lorandi
> > (Chile)
> > Sent: Tuesday, March 20, 2001 12:11 PM
> > To: Orion-Interest
> > Subject: RE: Why Entity EJBs?
> >
> >
> > I'm using EJB 1.1 CMP; It gives me as much DB independence as
> > I need. I have
> > to rewrite some finders when porting from DB to DB; hopefully EQL will
> > remove this burden too. Orion performs caching of instances, check out
> > exclusive-write-access and validity-timeout atrributes for
> > entity-deployment
> > tag in orion-ejb-jar.xml.
> >
> > However, if you have a distributed environment, cache's like
> > the one in
> > Orion are a threat to data integrity-- so they *must* be deactivated.
> >
> > Also, an orion-dependant feature, the boolean isModified(),
> > which in WLS is
> > called boolean isDirty(), plus a correct use of declarative
> > transactions
> > allow to minimize the impact on the DB.
> >
> > I believe CMP is the way to go, but it is very much
> > server-dependant. The
> > (apparent) poor performance of CMP is due to the need for
> > this solution to
> > address many things we all want from the server, such as data
> > integrity,
> > distribution across hosts of the business logic, declarative
> > transactions
> > and security. There's a price inherent to all this features,
> > and the larger
> > the spec, the higher the price we all must pay, basically, by
> > leveling down.
> > MS's single vendor approach actually levels up, but when they
> > don't have the
> > answers pre-packaged, all crumbles down and somehow we(as
> > developers) must
> > pay for the loses.
> >
> > Eventually, the servers *will* perform as expected, but until the spec
> > matures, we will be stuck with some minor problems. I'm now
> > living in Chile,
> > and the budgets are pretty tight here, but still, the
> > customer'd rather pay
> > for an extra box to scale up than to pay extra to the
> > programmers to do a
> > more optimized job and scale out. I'm aware that this is
> > vastly simplifying
> > the issue, but the point still stands.
> >
> > Perhaps the true problem is that we, all the J2EE developer
> > community, are
> > pushing it too far *and* too broad. This is what happened with CORBA,
> > leaving us with very little common ground. Some servers
> > implement mor of the
> > spec, some less. Some scale(but forbid Singleton's, for
> > instance) and some
> > don't. And there is no single way of making two OTS from two different
> > vendors to cooperate. CORBA was even taller than the Everest,
> > so nobody
> > climbed it.
> >
> > Of course, I also have those rush moments where I wonder why
> > I quitted my
> > older job, but that's definitely not the time to contribute
> > to anything.
> >
> > My 2c,
> >
> > JP
> >
> >
> > > -----Original Message-----
> > > From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, March 20, 2001 1:31 PM
> > > To: Orion-Interest
> > > Subject: RE: Why Entity EJBs?
> > >
> > >
> > > I also am questioning entity beans, after 5 months of intensive
> > > development with them. If you run Hypersonic in server
> > mode and watch
> > > the sql output to the console, it should be readily apparent
> > > why... CMP
> > > produces *WAY* too many queries for fine-grained entity beans.
> > >
> > > The biggest problem is finder methods. Since all beans are
> > > lazy-loaded,
> > > iterating through the finder results of 1000 beans will
> > > produce 1001 SQL
> > > calls. There isn't any reason specwise that beans cannot be
> > > eager-loaded, but few (if any) appservers seem to support this.
> > >
> > > Does anyone know if there is any support for eager-loading of finder
> > > results in Orion? There doesn't appear to be from the
> > documentation.
> > >
> > >
> > > I'm really disappointed in the entity bean concept. CMP
> > > should give us
> > > faster development times, faster code (with caching), and database
> > > independence, but at the moment we get *none* of the above.
> > > By stating
> > > in the blueprints that entity beans should only model course-grained
> > > objects and _not_ "one row of the table" they are effectively
> > > saying DO
> > > NOT USE CMP, because what is a CMP bean if not one row of a
> > table? I
> > > noticed that most of the new J2EE patterns Sun recently
> > > posted are aimed
> > > at BMP. Sun's schizophrenia on this really pisses me off;
> > > with one face
> > > they like to show off entity beans and CMP because MS
> > doesn't have it,
> > > with another they tell us to go back to the bronze age of
> > handwritten
> > > SQL because the technology doesn't work. Grrrrr.
> > >
> > > Jeff
> > >
> > >
> > > >-----Original Message-----
> > > >From: Dan North [mailto:[EMAIL PROTECTED]]
> > > >Sent: Tuesday, March 20, 2001 4:41 AM
> > > >To: Orion-Interest
> > > >Subject: Fwd: Why Entity EJBs?
> > > >
> > > >
> > > >Hi Johan.
> > > >
> > > ><two-pence-worth>
> > > >
> > > >I've been developing EJBs in a very (a) intensive and (b)
> > > >short development
> > > >cycle for about 5 months now. I've found that my methodology
> > > >has leant
> > > >towards what the JRF guys are talking about, but in a less
> > > formal way.
> > > >
> > > > From the backend forwards: I tend to use entity beans for
> > > >storing/retrieving and most manipulation of data - ie. I have
> > > >quite "fat"
> > > >beans rather than just purely getters and setters. I then
> > > use session
> > > >beans for workflow that doesn't seem to belong with any
> > > >particular single
> > > >bean, such as generating reports or anything that requires a
> > > few home
> > > >interfaces' finders. I also use session beans for their
> > > transactional
> > > >integrity when populating new beans from an HTML (JSP) form,
> > > >especially
> > > >when several beans will be created from a single form's
> > > >contents and I want
> > > >the whole lot to be atomic.
> > > >
> > > >We tend to use JSP and regular form beans for most of the
> > > >other workflow
> > > >stuff, and sometimes we'll have quite complex finder methods
> > > >in the EJBs
> > > >that join across several tables.
> > > >
> > > >The benefits to EJBs, and specifically orion, for me are:
> > > >- Database independence: we're deploying on MS SQL Server but
> > > >it's trivial
> > > >to deploy to eg. Oracle for scalability or Hypersonic for
> > > >local testing.
> > > >
> > > >- Network independence: I need to change no code to
> > cluster orion on
> > > >several hosts and also to split its responsibilities between
> > > >being a web
> > > >server on one host talking to another orion instance being an
> > > >app server on
> > > >another host.
> > > >
> > > >- Speed of development: I don't have to worry about how or
> > > >where my data is
> > > >being stored - I have orion's _fantastic_ OR mapping to do
> > > that for me.
> > > >
> > > >
> > > >It seems to me that the JRF is taking the "best practice"
> > > >approach, which
> > > >is a fine and noble thing to do, but then overcomplicating the
> > > >issue by
> > > >wandering off into its own specification.
> > > >
> > > >All my SQL for each package is in one place
> > > (orion-ejb-jar.xml), and I
> > > >don't have to worry about scalability or portability. If it
> > > >says J2EE on
> > > >the box, it'll usually have J2EE in the box. (Apart from the
> > > >usual niggles
> > > >with app servers being behind spec - again orion is pretty
> > > >good for being
> > > >up-to-date in this regard.) So I have all the benefits of JRF
> > > >but with the
> > > >backing of a technology as widely-adopted as J2EE.
> > > >
> > > ></two-pence-worth>
> > > >
> > > >Disclaimer: I don't work for orion, I just love their product.
> > > > And J2EE
> > > >has been the most useful technology I've discovered since I
> > > >picked up OO
> > > >about 10 years ago!
> > > >
> > > >Regards,
> > > >Dan.
> > > >
> > > >ps. That passage in the EJB book about having a session bean
> > > >talk straight
> > > >to a database is again (imo) a throwback to the technology
> > > >being pretty
> > > >immature and inefficient when the book was written. I have
> > > >had no problems
> > > >with orion's ability to manipulate and cache data for me
> > > >comparably well
> > > >with direct database access - but with the added benefit of
> > > >lots of data
> > > >integrity checking and no SQL on my part. In fact you get two
> > > >levels of
> > > >caching - the database and the app server.
> > > >
> > > >
> > > >>Date: Tue, 20 Mar 2001 09:22:52 +0100 (CET)
> > > >>From: Johan Lundberg <[EMAIL PROTECTED]>
> > > >>Subject: Why Entity EJBs?
> > > >>To: Orion-Interest <[EMAIL PROTECTED]>
> > > >>X-Mailer: Orion ListServer
> > > >>Reply-To: Orion-Interest <[EMAIL PROTECTED]>
> > > >>Sender: [EMAIL PROTECTED]
> > > >>X-MIME-Autoconverted: from 8bit to quoted-printable by
> > > >druid.evermind.net
> > > >>id KAA23094
> > > >>
> > > >>Hi
> > > >>
> > > >>The more I study the J2EE technology, the more I
> > > >>wonder why I should use it.
> > > >>
> > > >>The main reasons why I would use it are these:
> > > >>- Forget about the database layer while only using CMP
> > > >>entity beans.
> > > >>- Faster.
> > > >>- Scalable.
> > > >>- Easier to manage transactions.
> > > >>- Clear separation between client-workflow-persistence
> > > >>(JSP - Session beans - Entity beans).
> > > >>
> > > >>
> > > >>In our current system we use simple JSP, JavaBeans and
> > > >>a few connections to our database.
> > > >>We have made a few mistakes but we envisage cleaning
> > > >>up the system by starting from scratch. It is
> > > >>important that we choose the right technology but I
> > > >>get more and more sceptical about the EJB technology.
> > > >>
> > > >>We have experienced, when doing listings from a search
> > > >>page, that reading from the database and instantiating
> > > >>a few beans (not EJBs) takes a long time. The fastest
> > > >>way is to loop the resultset in the JSP-page, but it
> > > >>does have a few drawbacks and I would prefer to use
> > > >>another architecture.
> > > >>
> > > >>I thought that the pooled entity beans would speed up
> > > >>the system and started to study EJB.
> > > >>
> > > >>Then, Richard Monson-Haefel states in his book that
> > > >>listings shall be done directly between the Session
> > > >>bean and the database. Otherwise it would be too slow.
> > > >>I don't want to bother with SQL anymore and I would
> > > >>like to forget about the database layer, but it seems
> > > >>very difficult to get away with this requirement.
> > > >>
> > > >>To communicate between the JSP, the Session beans and
> > > >>the Entity beans, I get advised to use Data Access
> > > >>Objects. If I were to ignore the Monson-Haefel advise
> > > >>I would first create a bunch of Entity beans from a
> > > >>finder method, instantiate a collection of DAOs and
> > > >>send them back to the requesting Session bean. I
> > > >>wonder what kind of performance I would get from this
> > > >>system? I guess that this can become very heavy
> > > >>weight.
> > > >>It will probably become even more heavy weight when
> > > >>n-m OR-mapping becomes available.
> > > >>
> > > >>This will force us into a solution were we would have
> > > >>to use clusters and the scalability features of EJB
> > > >>comes handy. Is this the strategy from Sun - to make
> > > >>us buy more SUN servers?
> > > >>
> > > >>Now, what did I miss? Is there something that I have
> > > >>completely misunderstood? Please tell me what strategy
> > > >>we should use while developing CMP entity beans with
> > > >>Orion's OR-mapping features.
> > > >>
> > > >>I have found that another paradigm and framework that
> > > >>will simplify the development and reduce the amount of
> > > >>SQL-coding.
> > > >>
> > > >>http://jrf.sourceforge.net/ejb.html
> > > >>
> > > >>http://jrf.sourceforge.net/
> > > >>
> > > >>Why shouldn't we use this framework?
> > > >>
> > > >>Best regards
> > > >>
> > > >>/johan
> > > >>
> > > >>
> > > >>_____________________________________________________
> > > >>Do You Yahoo!?
> > > >>[EMAIL PROTECTED] - skaffa en gratis mailadress på
> > > http://mail.yahoo.se
> > >
> > > --
> > > Dan North
> > > VP Development - Cadrion Software Ltd - +44 (0)20 7440 9550
> > >
> > > CONFIDENTIALITY
> > > This e-mail and any attachments are confidential
> > > and may also be privileged. If you are not the named recipient,
> > > please notify the sender immediately and do not disclose the
> > > contents to another person, use it for any purpose, or store
> > > or copy the information in any medium
> > >
> > >
> > >
> >
> >
