Misi, This topic came up in a thread several weeks ago.
If you make a service call from an active link, the entire operation within the service call is done correctly with a single transaction. If you make a service call from a filter, the entire service operation is done within a transaction. HOWEVER, that service call is committed and is not wrapped into the larger transaction that the filter is a part of from the API call that triggered the filters. This last HOWEVER is not the desired behaviour and a bug has been created on the topic. The problem is not the service itself but the fact that the service called from a filter is committed rather than being part of the containing transaction. Now, there is likely one final oddity about this issue. Customers on Sybase and SQL Server probably see everything working just fine and the service call is part of the parent transaction and rollbacks occur correctly and such but customers on Oracle and DB2 find the behavior I note above. This is because Sybase and SQL Server have a concept of a nested transaction or transaction inside transaction. That is what happens in this case so those databases have the commit but it is a child transaction of a parent and if the parent rolls back, so does the child. But, Oracle and DB2 do not have the concept of a nested transaction. I am calling this out not to say there is no issue -- there is an issue and it should not be committing after the service call. I am calling it out in case some customers look at this situation and wonder what you are talking about and everything seems to be working. I cannot gaurantee that there is the difference in behavior (the system may have coded to close the parent transaction too), but just to observe that there is this fundamental difference in functionality about nested transactions so you may see different behavior on different databases. This bug is targetted to be fixed in a future release (no I don't know which one or whether it is targetted for a patch or in fact anything at all about the timeline for fix). Doug "the minimaly helpful" Mueller -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Misi Mladoniczky Sent: Friday, April 08, 2011 1:10 AM To: [email protected] Subject: Re: Push by an AL when error on FL Hi Doug, A follow up question on filters and transactions in connection with filter-service-calls. My experience with this is that a filter-service-call is also performed immediately, and that anything written to the database within the service-call is committed immediately (before the service returns). In other words the filter-service-call is not rolled back if an error occurs later in the filter processing. I want to make sure that this is by design, and that everyone is aware of the situation. It is both dangerous and powerful (if you know what you are doing)... Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. > Be careful that you consider whether you are talking about Active Links or > Filters. > > This question is about Active Links. > > IF it was about filters, then the question about transactions and whether > the push is committed if the > main operation failed would all be true. > > HOWEVER, this is about active links. Every action performed by an active > link is performed and committed > immediately. There is no delay. There is no transaction. Each action > for each active link is a discrete > operation and is performed to completion at the completion of the action. > > > My real question here is what is the bigger task you are doing. It seems > to me that you have BUSINESS > LOGIC encoded in active links. This is the error in your situation. > BUSINESS LOGIC for your application > should always be done in filters. Filters are run under a single > transaction and it is an all or none commit > (subject to your overrides of course). Active links are for screen > fiddling or for defaulting or for displaying > related data or the like. They should not be doing the business logic of > your application. Hence, there is > no reason for transactions or rollbacks or anything from active links. > > It seems to me like you need to move your logic from active links to > filters. Then, the push field will not > commit unless the operation itself commits. > > Something to think about, > > Doug Mueller > > ________________________________ > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of LJ LongWing > Sent: Thursday, April 07, 2011 10:01 AM > To: [email protected] > Subject: Re: Push by an AL when error on FL > > ** > Yes, the entire stack of updates is part of a single transaction, if there > is an error at any point, everything rolls back. > > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Adam Neidzwiecki > Sent: Thursday, April 07, 2011 9:11 AM > To: [email protected] > Subject: Push by an AL when error on FL > > ** > Hello, > > Anybody can help? > > I am on a form A and have an AL to push to a form B. > > This is happening when modifying A - no problem (no errors) > > Now, if there is an error returned by a FL - attached to form A - further > down the execution order. Will this error stop a push action done by an > AL to a form B? > > Thanks, > > Adam > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
