Jim,
FYI,
<vendor>
The Secant EES/EJB Container does provide CMP and does do "tuned updates".
"Tuned updates" is the default behavior for our Container but this behavior
may be controlled on an individual Bean basis.
</vendor>
DaveTillman
[EMAIL PROTECTED]
Director Professional Services
Secant Technologies
www.secant.com
----- 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.
>
> 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?
>
> > -----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.
> >
> > I had a similar mechanism in my RMI objects, although it stored any
> > attributes with a getter:
> > /** Analyzes the current object and stores the current state of the
> > * object in a hashtable. The hashtable will store all attributes
> > * of the instance class and its ancestors. Only attributes with a
> > * corresponding getXXX() method (and no parameters) will be
> > * stored.
> > */
> > public void mirror() {
> > hash.clear();
> >
> > Class myClass = this.getClass();
> > Method[] methods = myClass.getMethods();
> >
> > for (int i = 0; i < methods.length; i++) {
> > Method method = methods[i];
> > String name = method.getName();
> > Class[] parameters = method.getParameterTypes();
> > if (name.startsWith("get") && parameters.length == 0) {
> > Class returnType = method.getReturnType();
> > try {
> > Object o = method.invoke(this, null);
> > if (o != null) hash.put(name, o);
> > }
> > catch (InvocationTargetException itx) {/*shouldn't ever
> > happen*/}
> > catch (IllegalAccessException iax) {/*shouldn't ever
> > happen*
> > /}
> > }
> > }
> > }
> >
> > I then could get a list of attributes that changed by using:
> >
> > /** Returns whether the named method is modified. Useful for
detecting
> > * a change to a specific attribute. If the attribute has changed
> > * a Vector is returned that contains the previous and current
> > values:
> > *
> > * [0] - The value of the attribute stored in the hash
> > * [1] - The class instance's current value for the attribute
> > *
> > * If no changes are detected the return value will be null.
> > */
> > public boolean isModified(String methodName, final Object[] values)
{
> > values[0] = null; values[1] = null;
> > Class myClass = this.getClass();
> > Method[] methods = myClass.getMethods();
> > Object o1= hash.get(methodName);
> > for (int i = 0; i < methods.length; i++) {
> > String name = methods[i].getName();
> > if (name.equalsIgnoreCase(methodName)) {
> > Object o2 = null;
> > try {
> > o2 = methods[i].invoke(this, null);
> > }
> > catch (InvocationTargetException itx2) {}
> > catch (IllegalAccessException iax2) {}
> > if (o1 == null) {
> > if (o2 != null) {
> > values[1] = o2;
> > return true;
> > }
> > continue;
> > }
> > if (!o1.equals(o2)) {
> > log("Is modified on method: " + name);
> > log("Stored value: " + o1 + ", Instance value: " +
> > o2);
> > values[0] = o1;
> > values[1] = o2;
> > return true;
> > }
> > }
> > }
> > return false;
> > }
> >
> > Basically, you would call mirror() in the ejbLoad() method, and use the
> > isModified() to determine which fields you add to your update query in
the
> > ejbStore() method.
> >
> > 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".
