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 API call was a bad corrupted index for one of the Filters that fired for the Modify API call. :| Once we fixed that index, we were able to configure our test bed server with a Private Program Number having min - 4 threads / max - 12 threads and had the Java program hit it with 100 Java threads. We were able to get a throughput of 4 records completing Modifications per second. Arthur Carey Matthew Black wrote: > > 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" > > -- View this message in context: http://www.nabble.com/Modify-a-View-Form-entry-using-Java-API-tf4308465.html#a12285395 Sent from the ARS (Action Request System) mailing list archive at Nabble.com. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
