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
-----Original Message-----
From: Jim Frentress <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, May 14, 1999 4:55 PM
Subject: Entity no more expensive than Session: WAS: findLargeAccounts - w
hy bother?
>Imre made the statement and i must admit that i tend to agree. We use
>Session almost exclusively for bootstrap and client state.
>
>I'm less fond of "wrapping" entity with session than apparently most
posters
>to this list. I have a feeling that it's because ITM is using EJB in
>production so we have to solve real-life problems rather than academic
ones.
>
>I'm perfectly willing to be enlightened as to why I'm not properly educated
>on the topic. I can say that our system does not appear to be constrained
on
>the appserver level (eg EJB) and as far as we can see, we're scalable there
>far into the future with clustering.
>
>So, who out there has a non-trivial system *in production* under EJB and
has
>something to say about this?
>
>> -----Original Message-----
>> From: Imre Kifor [SMTP:[EMAIL PROTECTED]]
>> Sent: Friday, May 14, 1999 11:30 AM
>> To: [EMAIL PROTECTED]
>> Subject: Re: findLargeAccounts - why bother?
>>
> <snip>The
>> idea is to treat both entities *and* collections of entities as "first
>> class" citizens. Since entity beans are no more expensive than session
>> beans, we use entities for the collections to take advantage of
>> CMP/caching/sharing and to have finer control of the bean instances. As a
>> matter of fact, we use session beans in our customer's architectures only
>> when client (or session) info has to be maintained on the server.
>>
> <snip>
>
>===========================================================================
>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".
