BOR and Perfmance

[Mark Huffman]

Hi Alon,
 
If I am troubleshooting some very bad method code where the original
programmer tries to do several different things inside of one method and has
commits all over the place, what would you recommend? Often this type of
code is assoicated with intermittent (and sometimes frustratingly so)
runtime problems.
 
As for your original issue, I was under the impression that you could not
rely on a database refresh eg. the instance is resused as you put it, if for
example attribute values were updated, and you always needed to force a
refresh to be sure that you were reading the latest data.
 
Mark
----- Original Message -----
From: "Alon Raskin" <araskin at 3i-consulting.com>
To: <SAP-WUG at MITVMA.MIT.EDU>
Sent: Monday, July 19, 2004 3:09 PM
Subject: Re: BOR and Perfmance
 
 
> Hi Mark,
>
> I am all for the use of swc_refresh_object. I am a bit surprised about the
> COMMIT WORK AND WAIT though because I was under the impression that it was
a
> cardinal sin to do a COMMIT WORK inside a method (since the Workflow
> sub-system does one for you). I would be interested in hearing what people
> have to say about that one.
>
> What I was trying to find out in the previuos post is whether an instance
> lives is reused in subsequent steps of a workflow or is it re-instantiated
> every time? From what I gathered from Michael, as long as the advance with
> dialog flag is checked then the instance is reused (which is good).  I
hope
> this holds true for tasks that are running under WF-BATCH in background?
>
> Alon
>
> -----Original Message-----
>> From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of Mark
> Huffman
> Sent: 19 July 2004 20:02
> To: SAP-WUG at MITVMA.MIT.EDU
> Subject: Re: BOR and Perfmance
>
> Alon and Mike,
>
> I have done a lot of production support jobs in the past few years and in
> general have often used swc_refresh_object SELF to tidy up custom methods
> that were making timing assumptions and causing errors.
>
> These days I try to avoid using 'commit work and wait' in background
posting
> methods, but sometimes resort to that as well, especially where the code I
> am trying to troubleshoot has commits sprinkled all through it.
>
> Mark
>
>
> ----- Original Message -----
>> From: "Michael Pokraka" <workflow at quirky.me.uk>
> To: <SAP-WUG at MITVMA.MIT.EDU>
> Sent: Monday, July 19, 2004 1:39 PM
> Subject: Re: BOR and Perfmance
>
>
> Hi Alon,
> I think in theory if 'advance with dialog' works then it would also retain
> the object instance.
> In practice however it just goes plain weird. I had an issue on 4.6c with
a
> virtual attribute that didn't have a 'CLEAR' after the 'DATA' statement.
Not
> strictly necessary one may think...
> WRONG! The attribute was used in the inbox description. Displaying it and
> then clicking on another workitem which DIDN'T have a value for that
> attribute would show the previous item's attribute value. So somehow it
was
> buffered across instances when using the inbox.
> I asked OSS about the theory/mechanics behind this without much success.
>
> Could I also add to the original question the idea of a Persistent Object
> Reference in this context... does that improve buffering or make it worse?
>
> Cheers
> Mike
>
> Alon Raskin wrote:
> > Hi Everyone,
> >
> > I trust that everyone had a good weekend.
> >
> > One of the nice things about the BOR is the buffering approach that it
> > provides. When you first access a Dictionary attribute, the whole
> > record
> is
> > retrieved and stored in a structure so any subsequent accesses to
> Dictionary
> > attributes do not result in a call to the DB.
> >
> > My query is: Between two steps of a workflow, are all the BOR object
> > instances re-instantiated? I got the feeling that they were but was
> unsure.
> > If that is the case then doesnt that defeat the whole purpose of the
> > buffering approach?
> >
> > I look forward to your thoughts/comments.
> >
> > Alon
> >
> >
>
>