see below
----- Original Message -----
From: Jim Frentress <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 17, 1999 10:48 AM
Subject: Re: Tuned Updates & BMP
> i'm probably missing something but why not simply keep an array of
> persisting attributes as they mutate. in ejbStore, when the array has
> members, generate the statement from them.
>
With this approach, you will have to place logic to update this array in
every setter. While this works, the hash concept would achieve the same
thing, but with no "intrusion" into the business logic.
> as a side note, there are huge performance and scalability issues with
> containers that do not tune their updates. most of these issues are a
result
> of the underlying pstore's logging of large datatypes (image, text, etc.)
>
> i know of just one container that tunes updates. can anyone enumerate a
list
> of containers that do tune updates?
>
I was referring to Inprise EJB Server
> > -----Original Message-----
> > From: James Cook [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, August 17, 1999 7:15 AM
> > To: [EMAIL PROTECTED]
> > Subject: Tuned Updates & BMP
> >
> > To borrow a phrase from Jim Frentress:
> > Tuned Update - the process of persisting only the EJB fields that have
> > changed.
> >
> > I suppose most well-behaved containers will use tuned updates within
their
> > CMP infrastructure. My current container does, and it helps a great deal
> > to
> > eliminate the concurrency issues associated with one user wiping out a
> > change made by a previous user.
> >
> > This, of course, does nothing to assist me in BMP. I have to manage this
> > concurrency issue myself. My EJB structure follows the segregated design
> > fundamentals discussed in earlier threads. All of my EJB's extend an EJB
> > superclass. Would it make sense to use reflection and a hashtable in
this
> > superclass to store the pre-write state of an EJB? When a write occurs,
I
> > can then compare the current attributes against the hash to determine
what
> > fields to write.
> >
<snip>
> > Has anyone come across this situation?
> >
> > jim
> >
> >
==========================================================================
> > =
> > 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".
