Hi Richard,
One last thing..
[richard] Anyway, after we finish loading every single employee record in
the data base into hundreds (possibly hundreds of thousands) of Employee
beans we then proceed to create thousands of EmployeeDetial beans to send
back to the client.
[william] The thousands of records issue has already been addressed in my
previous post under [RE: Paging large database result sets]. This statement
is not valid here - a bit extreme would you agree.
I just read one of my previous posts which stated incorrectly that I like
the rowset thingy. I know the comfort this gives to people coming from a
background in PowerBuilder or Visual Basic but to me this is something the
client/server sphewed out into the GUI and was abused by everybody. Has
anybody every seen the mess this creates under the covers of the client
application. I was horrified but not surprised when Silverstream introduced
this concept under a slightly different guise in the early days (could SS
users confirm if this still exist in version 3.0).
Richard, you are right about my heart but I do also try to use my mind
though I suspect my heart sometimes wins over. How could people work in this
crazy industry without have some passion for their work.
Now I am really late....
kind regards,
William Louth
Inspired Consultancy
Distributing solutions throughout the Enterprise
> -----Original Message-----
> From: Louth, William (Exchange)
> Sent: Thursday, April 27, 2000 6:42 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Cached Rowsets-do we need to use them
>
> Hi Richard,
>
> I am still trying to formulate a comprehensive posting to you but before I
> log off for tonight (I have dinner-meeting) I must provide one
> qualification to what I am advocating. You state that the access of state
> through entity beans is too expensive.
>
> [richard]
> First, in order to get the data we have to use an ejbFinder method to get
> a
> remote reference to an entity bean for every employee in the enterprise.
> This
> alone would cause so much latency as to be prohibitive, but that's
> William's
> strategy since he has advocated keeping everything in an object like
> representation. Anyway, after we finish loading every single employee
> record in
> the data base into hundreds (possibly hundreds of thousands) of Employee
> beans
> we then proceed to create thousands of EmployeeDetial beans to send back
> to the
> client.
>
> [william]
> OK, here is the qualification which I expect will have people booing or
> cheering. I can achieve the same with cmp as your sql if I use an ejb
> container like Inprise Application Server 4.0 that has been built to
> reduce any performance overhead associated with entity bean access. How
> does IAS finder mechanism achieve this? The IAS cmp engine will issue a
> select statement just as you will do. The select can be configured to
> return all of the fields for the entity bean i.e. select pk, fld1,
> fld2....from table.... where..... The cmp container will then return a
> collection of entity beans initialized with the data from the returned
> resultset. This collection returned to the session bean can then be used
> to create the details list by calling getDetails() or something similar on
> each entity bean. The are some factors here which make this all pretty
> fast which are better stated by the guy behind them.
>
> [Jonthan Weedon]
> From: Jonathan K. Weedon [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, March 31, 2000 7:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: 'local' entity beans vs dependent objects
>
> As do other vendors, we support the ability to turn on or off PbV
> verses PbR. However, when asked to provide PbV semantics, we apply
> this rule on an argument-by-argument basis. Thus, if your signature
> contains only numbers, strings, dates, etc., then we don't do the
> argument copying (since it is unnecessary). Which means that the
> performance overhead of pass-by-value is only an issue for things
> like LineItems if they contain complex data types (such as Vectors)
> AND if they rely on PbV for their manipulation of such types (which
> is unusual, in and of itself).
>
> Remember that we are simply making LineItems into entity beans. If
> the LineItem were a dependent object, then it would already be using
> PbR semantics, and you would already have to be careful to not modify
> parameters, etc. In the real world, most Java developers know how to
> write code that uses PbR, since that is how they write all their
> normal (non-distributed) code anyway!
>
> Of course, to make colocated calls efficient, you need to avoid all
> the other baggage: marshaling, stubs/skeletons, security checks, etc.
> Avoiding this overhead is one of the marks of a good server. If a
> server can't do this...
>
> The other requirement for supporting large numbers of smaller-grained
> entity beans is making the JDBC access efficient. Users of our products
> know that we have implemented a large number of optimizations to avoid
> all the typical problems associated with using entity beans: tuned write,
> automatic read-only access detection, caching of state across finder
> calls and bean access, etc. Our goal was to make using entity beans
> as fast as writing the SQL yourself, or in many cases even faster.
> (For example, when you write the SQL yourself, you have to recreate
> your prepared-statements; our JDBC code knows to reuse prepared-statements
> across transactions. You might be surprised how big an impact that one
> small optimization has, and unfortunately it is an optimization that
> cannot be made in a server-independent way for BMP beans, or for session
> beans which do their own SQL.)
>
> kind regards
>
> William Louth
> Inspired Consultancy
>
>
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
