From: "Robert G." <g...@mercon24.de> > ok now I used require-new-transaction="true" within the service declaration > in services.xml. This seems to work. It imports all data (all rows are > proceeded). > > "Attribute : require-new-transaction > If set to true and there is a transaction already in place the Service > Engine will suspend that transaction, > begin a new one just for this service, commit or rollback the local > transaction when the service is > complete, and will resume the original transaction. If set to true and > there is no transaction already in > place it will just begin a transaction and manage it as would be done for a > normal user-transaction=true. > If use-transaction=false this setting is ignored." > > I understand it that it pauses an active transaction, when a new one > arrives, and resume it after the new one is ready, right?
Yes, by using require-new-transaction="true" you suspend the (surrouding) transaction in which your Groovy file is (I guess you have one "automatically", normally you should), and create a new one for your called service. Else the current (surrouding) transaction, in which your groovy file was called, will be used by the called service. By using require-new-transaction="true", the suspended (surrouding) transaction is then resumed when the called service finishes. So it seems from your result (I never tested that) the suspended transaction see also its timeout "suspended". Which is why it would work for you. Interesting if true (I did not check the code), I see only this explanation Note that by default the time out of a transaction is 60 seconds (defined in the Transaction Manager). By using require-new-transaction="true" you can set a higher (or different at large) time out for a called service if necesssary. require-new-transaction="true" is only necessary for a service timeout to work if you are inside a previous transaction. Another solution would have been to set a very high timeout on the action which is the origin (a request event I guess). But AFAIK this would work only if the surrounding call is a service. Because events (w/o service call) in requests use a transaction but there are no ways to set a timeout. So the default 60 sec would apply. If your event use a service, then another solution would have been to set a high timeout without using require-new-transaction="true". Because this is only needed for services called inside a service. This near what suggested Adrian, to set the surrounding call in which you groovy file is, to not use a transaction, hence no timeout. But again this would only work if the event which eventually calls the service in the loop is itself a service. And, by and large,it's always better to set a timeout purposedly thantnot using a transaction. Last but not least there is a specific trap, see https://issues.apache.org/jira/browse/OFBIZ-5183, which remembers me to do the point 1! HTH Jacques > I think this is fine so, what do you think? > > > > -- > View this message in context: > http://ofbiz.135035.n4.nabble.com/Groovy-call-a-service-within-a-while-loop-wait-notify-tp4641435p4641441.html > Sent from the OFBiz - User mailing list archive at Nabble.com.
