Jim,
I am curious, why have you found it nessary to wrap primitive types
to "make the system usable"?
-Chris.
> -----Original Message-----
> From: Jim Frentress [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 14, 1999 7:57 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Entity no more expensive than Session: WAS:
> findLargeAccounts - w hy bother?
>
> On a related topic, what does the list think about using native vs
> reference
> types for persistent fields in an EJB? We've found, unfortunately, that
> reference types (Integer, Long, etc...) are really pretty much required to
> make a system usable. This has the negative impact of lots and lots of
> object creation and gc. What strategies are people using to mitigate 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".
===========================================================================
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".
