Thanks for the help. I will play around the code and check the difference. I will reply with my findings to update this thread.
On Mon, Mar 9, 2009 at 3:10 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > From: "Hansen Wang" <han...@gemmall.com> > >> 1. Yes. The transaction is rolled back. >> 1'. Yes. The global transaction include many services and one of them is >> changeOrderStatus. >> 2. No. This can happen regardless whether the capture fails or not. This >> happens for 1 out of 50 orders in my server. I have a work-around to >> include >> code to check the order status in sendOrderCompleteNotice. If the order >> status is not Completed, then it will log the information and do not send >> the email. >> >> The following will further explain what I am doing. I wrote a >> massShipOrders >> services which process a batch input file with three columns (orderId, >> trackingNumber, shippingMethod, shipGroupSeqId). This service iterate each >> line of the input file and invoke gemmallQuickShipOrder which is a service >> group. Please note that massShipOrders does not use transaction because >> the >> failure of one record should not affect the rest. >> >> I have further question regarding to your reply. Isn't that >> "global-commit" >> and "commit" are the same, regardless the number of services invoked, if >> there is only one transaction? Please clarify as I was not able to find >> out >> related information from the docs. >> > > that "global-commit" and "commit" are not the same. > If you build a process which includes services in a sole transactionn, the > condition using global-commit event for a particular SECA will only be > satisfied iff the (global) transaction succed. This could be a way for you > to wrap all your related services in one transaction to be sure that only if > all services succeed (which is approximatively the same than the transaction > succeed) a particular SECA would be activated. > > Also about use-transaction="false", note that even if the service does not > use its own transaction it can be embedded in (an)other surrounding > transaction(s). Though even if it's embeded it will not commit, but , and > this is a bit surprising, it will anyway end, and this will activate any > corresponding condition in SECAs using commit as event. > > HTH > > Jacques > > > These are the related services mentioned. >> >> <service name="gemmallQuickShipOrder" engine="group" >> use-transaction="true" auth="true"> >> <group name="gemmallQuickShipOrder"> >> <invoke name="updateOrderItemShipGroup" mode="sync"/> >> <invoke name="updateTrackingNumber" mode="sync"/> >> <invoke name="quickShipEntireOrder" mode="sync"/> >> </group> >> </service> >> >> <service name="massShipOrders" engine="java" use-transaction="false" >> location="org.ofbiz.order.order.OrderServices" >> invoke="massShipOrders" auth="true"> >> </service> >> >> Thanks >> Hansen >> >> On Mon, Mar 9, 2009 at 11:20 AM, Jacques Le Roux < >> jacques.le.r...@les7arts.com> wrote: >> >> I did not check any details but >>> >>> 1) If payment capture fails is the changeOrderStatus rolled back ? If not >>> it's a normal behaviour and you should try to add a condition-field >>> related >>> to payment capture. >>> 1') As I said I did not look into details but if the payment capture is >>> part of a global transaction which includes both changeOrderStatus and >>> payment capture you could try "global-commit" instead of "commit" >>> 2) Is this happening only when payment capture fails ? >>> >>> Jacques >>> >>> From: "Hansen Wang" <han...@gemmall.com> >>> >>> Hi, >>> >>>> >>>> I am using release4.0 and am having the following problems in >>>> quickShipEntireOrder. >>>> >>>> 1. An order complete email is sent even if payment capture failed. >>>> >>>> 2. An order complete email is sent with status as "Approved" instead of >>>> "Complete" even when the service succeeded. >>>> >>>> The following is the related eca relating to the order complete email. >>>> >>>> <eca service="changeOrderStatus" event="commit" run-on-error="false"> >>>> <condition field-name="statusId" operator="equals" >>>> value="ORDER_COMPLETED"/> >>>> <condition-field field-name="statusId" operator="not-equals" >>>> to-field-name="oldStatusId"/> >>>> <action service="resetGrandTotal" mode="sync"/> >>>> <action service="sendOrderCompleteNotification" mode="async" >>>> persist="true"/> >>>> </eca> >>>> >>>> Based on this eca, sendOrderCompleteNotification should not even be >>>> invoked >>>> if changeOrderStatus failed because it is invoked before the commit of >>>> the >>>> transaction and the transaction should be marked as rollback. >>>> >>>> Problem #2 seems to do with database concurrent accessing. The problem >>>> is >>>> that when the eca is invoked, it is comparing the status from the >>>> parameter. >>>> However, sendOrderCompleteNotification is accessing the data (order >>>> status) >>>> from the database. It is possible that sendOrderCompleteNotification is >>>> commited before changeOrderStatus and in that case it will read the old >>>> status (which is the behaviour of read committed). >>>> >>>> So my questions are why #1 happened? Is #2 an expected hahaviour and how >>>> can >>>> it be improved in a robust way? >>>> >>>> Thanks, >>>> Hansen >>>> >>>> >>>> >>> >>> >> > >
