same reason that NULL is an option in rdb's. if you don't use reference types, how do
you determine if an int has been set by the user or defaulted by Java? even if you can
determine this, how do you get a CMP attribute to remain as NULL until explicitly set
by the user? for many systems, default (eg non-NULL) values are not acceptable. better
solutions to the problem are welcome.
-----Original Message-----
From: Chris Raber [SMTP:[EMAIL PROTECTED]]
Sent: Monday, May 17, 1999 8:30 AM
To: [EMAIL PROTECTED]
Subject: Re: Entity no more expensive than Session: WAS: findLargeAccounts - w
hy bother?
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".
===========================================================================
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".
