Hi Imre:
Coud it be that one reason to wrap entity beans inside session is to
alleviate clients from having to deal with transaction demarcation, or
having to know about transaction attributes of the entities? It seems
to me that by wrapping entities inside sessions I have a better
handle on transactions, and relieve that responsibility from
clients.
As for session time outs on *stateless* session beans. Is it possible
that some container implementations will always maintain a couple of
stateless instances on a pool at all the time? And in that case we
would not have the problem you described. BTW, I think that stateful
session beans would not have the mentioned problem unless the remove
is explicitly called on the bean. Otherwise, it seems that a later
call on the statefull session bean would activate it from disk.
Thanks in advance for your comments.
--
Rubens S. Gomes, Software Development Engineer
Fujitsu Network Communications, Inc.
ATM Network Management Systems Development Group
1000 St. Albans Drive, Raleigh, NC 27609 USA
Tel: 919.790.2539 Fax: 919.790.3330
On Sat, 15 May 1999, Imre Kifor wrote:
> 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".
>
>
===========================================================================
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".
