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 complete until after all filters for that ARS Server operation has completed. If you think of ARS as an application server then I think your applying a bit to "modern" of a model than what ARS is actually modeled after. I think you need to consider ARS more of an data store in the more modern "application server" model. In fact I have often thought of filters more as a RDBMS trigger than as a "workflow engine" portion of an application server. ( And I can easily see how modern programmers would see them differently.) So... in short... until after all of the filters have finished, the ARS server does not commit (fully) the RDBMS data changes that might be necessary for the API call. And thus, the event is not complete until the transaction is fully committed to the data store. Then the ARS server returns a "status code" describing any Messages or error conditions that were issued during the transaction back to the caller. That is the completion of the API call. Or at least that is how I see the ARS API universe. Now if you turn to the C API, there might be a better option... Specifically I would look at ARBeginBulkEntryTransaction as a possible way to package and send multiple transactions as a single unit. You however get a list of "status code"s per each api call that was sent in the BulkEntry. Maybe in the v7.1 Java API there will be an equivalent ARBeginBulkEntryTransaction type of function, but for now, I do not know of any interface to that feature set of the C API. But I will also add... that I would expect the client program to be "held" waiting for the list of status codes from the bulk transaction just as it would for a single transaction. I just hope that there is some efficiency's gained by sending them as a set instead of in multiple trips across the network. I would also expect that multiple server threads would be tied up dealing with a single ARBeginBulkEntryTransaction too. (But that is mostly speculation as I do not speak C. :) Hope that helps. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 8/21/07, arthurj <[EMAIL PROTECTED]> wrote: > 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 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
