Thanks Carey.
That was helpful...
Since I come from the DB bunch, I too think of Filters as RDBMS Triggers.:)
And you are right, with Bulk Transactions, i would expect some benefit from
preventing mutliple trips across the network.
We finally found that the delay in a thread going to the next AP
Use Merge with the NoWorkflow option (a bit pattern available since ARS 6+)
instead of Modify AND set a real database field so that an escalation fires the
real Modify workflow. Obviously, build that escalation.
You are getting around the basic design of ARS in this way and this must be
done w
Arthur,
"each thread would be relieved as soon as the modify of that one
record is completed in the View form"
You are completely correct about that. However, where you think
"completed" should be reached is actually not where it actually ends.
The transaction (or API call if you prefer) is not
I would think that each thread would be relieved as soon as the modify of
that one record is completed in the View form and not wait for the Modify
filters depending on that Modify to complete, since there are no Filters
with names ending in "`!".
Arthur
arthurj wrote:
>
> Thanks Carey.
> The J
Thanks Carey.
The Java program I mentioned earlier is a multithreaded app which sends in 8
threads to a Private server 390682 (min 4 and max 8 threads). Each thread is
a Modify request to that View form.
>From the logs it seems like every thread waits for all the relevant Modify
Filters to complete
Dear Arthurj (software_architect),
To my knowledge there is no way to alter the atomic nature of the ARS
API. (vai the Java API or the C API.) The "trick" is to realize that
the ARS server is a multi-threaded server. You can control how your
client talks to the ARS server and how many threads are
6 matches
Mail list logo
