Ed,
Here is why I very strongly oppose this unrestrained session bean wrapping
idea. Any call on a session object can throw an "object expired" exception
(remember the session timeout?). This means that in the client *every* call
(to session objects) has to be protected and at *any* level you have to
support the recreation of the session objects. If this is not an artificial
complication of the client code then I don't know what is.
Of course, you can set the timeout to something large, however, then you
disable the resource management capabilities of the server and still have to
complicate your client code hopelessly.
One other issue (that we ran into!). The session timeout can be changed long
after the client code has been completed (and shipped). If you assume that a
deployer decides to make the server "more scalable", and cuts back the
session timeouts in masse in the deployed beans, chances are that your
clients will fail with unexpected and extremely difficult to track
exceptions due to object expirations. And all that will happen on the client
code visible to your best customers.
Having developed both the server *and* the client side of non-trivial EJB
apps, I would have to say that anyone recommending session wrapping en masse
is 1) misleading people about the ease of use of EJB and 2) doing great
disservice to EJB.
>PS: I don't buy the distributed GC argument. Clients keep references to
EJB
>objects, not entity bean class instances.
If you read the posting more carefully you will realize that no one ever
mentioned bean instances.
Imre Kifor
Valto Systems
-----Original Message-----
From: Ed Roman <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Saturday, May 15, 1999 4:48 AM
>Wrap entity beans with session beans for performance. If your EJB system
is
>distributed across multiple tiers, you don't want a network roundtrip on
>every get/set method that you call on entity beans. Session beans can act
>as bulk access providers to session beans, allowing you to call one session
>bean method that performs many entity bean operations. This enhances
>network performance. You cannot put the bulk access methods in the entity
>bean itself, because the bulk access could involve several DIFFERENT
>top-level entity beans.
>
>Note: You can sidestep network performance problems by deploying your
>enterprise beans and their clients in a single tier. However, as soon as
>you shift to a multi-tier deployment, your performance will be hosed. If
>you wrap entities with sessions, you have a high-performance solution that
>works in any tier combination. Combinining enterprise beans with their
>clients in a single tier is not an option sometimes either. For security,
>companies occasionally need to segregate their deployment with firewalls
due
>to security reasons. Other companies need deployments involving multiple
>heterogeneous enterprise domains, such as departmental or corporate
domains.
>
>PS: I don't buy the distributed GC argument. Clients keep references to
EJB
>objects, not entity bean class instances. The container can release the
>entity bean class instance regardless of what the client is doing, and
>instantiate it again later if necessary. Anyway, this is a systems-level
>issue, not an application-level issue.
>
>(On a related note, can anyone come up other reasons besides these on why
>you'd need to seperate a servlet/JSP/ASP layer and an enterprise bean layer
>into two different tiers? After all, these days the major app server
>support both GUI logic and enterprise beans deployed in a single tier.
>Maintenance is better with a single tier (half the machines to administer),
>performance is better (no network between GUI logic and business logic), DB
>connections can still be pooled, thread priorities can be tuned to give
>priority to tasks within the app server, and new machines can be added for
>scalability. Load-balance HTML requests between the machines with a
>packaged box and you've got a deployment.)
>
>>From: Jim Frentress <[EMAIL PROTECTED]>
>>Subject: Re: Entity no more expensive than Session: WAS: findLargeAccounts
>>- why bother?
>>Date: Fri, 14 May 1999 17:06:35 -0700
>>
>>I'd be extremely interested in more feedback on this, especially the
>>perspectives of CORBA based vendors (IBM (im), Inprise (jw), Oracle >
>>(hh)).
>>I'd also love to hear what WebLogic (ss) thinks about this.
>>
>>-----Original Message-----
>>From: Imre Kifor [SMTP:[EMAIL PROTECTED]]
>>Sent: Friday, May 14, 1999 4:09 PM
>>To: [EMAIL PROTECTED]
>>Subject: Re: Entity no more expensive than Session: WAS:
>>findLargeAccounts - w hy bother?
>>
>>Jim,
>>
>>The reason for this tendency to wrap entity beans with session beans is
>>that, on certain platforms, entity objects cannot be released after use.
>>
>>This issue causes great difficulty for servers written in languages other
>>than Java (i.e. based on CORBA). Java servers, however, can take advantage
>>of distributed GC. Well, sort of. DGC is not exactly useful for JDK1.1
>>based
>>servers. The servers themselves need to hold on to the entity objects so
>>that they can pass them out to the next client. Of course, then GC cannot
>>reclaim the objects, hence even with JDK1.1 based servers, temporary
>>entities are a no-no.
>>
>>With Java 2 the situation changes drastically. A Java 2 based server can
>>hold on to entity objects with "weak" references, thus allowing unused
>>entities to be collected automatically. As you already know, being able to
>>create entities on the fly dramatically increases server resident data
>>reuse
>>and decreases unnecessary session object creations and maintenance. The
>>downside? One would say DGC. However, DGC is used regardless whether you
>>access session or entity objects. Actually, chances are that with entity
>>references you will need less DGC since you are passing around fewer
>>remote
>>references.
>>
>>Do I need to say that Ejipt is based on Java 2 and is taking full
>>advantage
>>of the scalable server features of the platform ? :-)
>>
>>Imre Kifor
>>Valto Systems
>
>
>
>_______________________________________________________________
>Get Free Email and Do More On The Web. Visit http://www.msn.com
>
>===========================================================================
>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".
>
===========================================================================
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".
