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 > > -----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". =========================================================================== 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".
