Ahhhh! You are absolutely right, and I marvel at my own foolishness!
It was something in my code that made it look like finders were issuing
n+1 calls. That, combined with my expectation of trouble because this
question (about n+1 sql calls for a finder) comes up with some
regularity on the ejb-interest mailing list. I don't think many of the
(other) appserver vendors have a satisfactory solution.
My faith in CMP has been restored. I'm finding that hacking around
case-sensitivity in String values is annoying, but it still beats
handwriting SQL.
Thanks Magnus! It's too bad that Sun doesn't espouse this same line of
thought; it's pretty clear to me now that the arguments against
fine-grained entities are largely a product of deficient container
implementations.
This should be a FAQ.
Jeff
>-----Original Message-----
>From: Magnus Stenman [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, March 20, 2001 10:33 AM
>To: Orion-Interest
>Subject: Re: Why Entity EJBs?
>
>
>Orion should execute one SQL query for a finder (even with
>1000 rows) unless:
>You're using BMP.
>You're using exclusive-write-access="false" and are outside of a TX.
>
>BMP is less than slim when it comes to SQL activity, we
>generally recommend CMP unless the condition is exceptional.
>
>Another "common mistake" in EJB usage is not using
>transactions. The same code can generate 100x+ as many calls
>when run outside of a TX as inside a TX. Why this is specific
>to EJB is that EJB treats data integrity very carefully, while
>your "home brewed" (hope that word isnt offensive) access may
>delay persistance into larger chunks etc (a "semi TX").
>
>So: avoid exclusive-write-access="false" unless absolutely
>needed, use CMP if possible, and identify where your app is
>really "TXs" logically but isnt defined to be.
>
>What you get: cleaner and more easily abstracted code if all
>goes well. Transactional (and distributed, stay tuned some
>longer for that to come clustering doc) cache (it is fairly
>easy to make a cache, but another issue alltogether to make a
>transactional cache that scales, totally different tasks).
>More ease in code migration between programmers since you're
>closer to the "default", more of the backbone has been
>provided/standardized.
>
>Weakest side of entities as of now: batch updates. No
>candidate to that one, it is the biggest limitation (but can
>be worked around).
>
>As for "general design standpoint" it is usually not good
>custom for a vendor to push a practice; but we can say as much
>as that our recommendations are pretty much in line of those
>described by Dan North in a recent reply to this thread (CMP,
>logic in entities that apply to that entity - ignore the
>recommendation stating that they're simply data storage items,
>they're objects, and inter-bean logic in sessions).
>
>Just a short note... we rarely mix into this category of
>discussions (the ones bordering on religious beliefs ;) but I
>thought I'd shed some technical light on some of the issues -
>everyone's free to chose their own architecture, but it's sad
>when it's done due to lack of knowledge of architecture X's
>facts and benefits.
>
>Have a nice day!
>
>/Magnus Stenman, the Orion team
>
>PS. On the issue of "coarse grained" - entities fit perfectly
>well for fine grained access, but this is a political battle.
>You may have heard rumours about "local" entities, which
>consist more or less of entities allover but "allowed for fine
>grained access" this time. Our current position on that matter
>is that locals are superflous, what needs to change is just
>the notion of EJBs always being coarse grained. This is, of
>course, a very preliminary position. If there turns out to be
>genuine technical merits for the separation (things that
>cannot be done feasably via switch tags in the descriptor, see
>for instance copy-by-value in orion-ejb-jar.xml) that weight
>enough we'll reposition.
>
>/Magnus Stenman, the Orion team
>
>
>----- Original Message -----
>From: "Jeff Schnitzer" <[EMAIL PROTECTED]>
>To: "Orion-Interest" <[EMAIL PROTECTED]>
>Sent: Tuesday, March 20, 2001 6:31 PM
>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
>>
>>
>
>
>
