service engine bug with rollback?

[Si Chen-2]

Has anybody noticed this?  It seems sometimes when use-
transaction="false" we're still getting a rollback when a service  
returns an error.

Si
[hidden email]

[David E Jones-2]

A rollback, or a setRollbackOnly?

-David


On Oct 20, 2006, at 4:14 PM, Si Chen wrote:

> Has anybody noticed this?  It seems sometimes when use-
> transaction="false" we're still getting a rollback when a service  
> returns an error.
>
> Si
> [hidden email]
>
>
>

[Si Chen-2]

David,

It is a setRollBackOnly, kind of like this:
20 Oct 06 18:42:55[    TransactionUtil.java:247:INFO ]  
[TransactionUtil.setRollbackOnly] transaction roll back only set
20 Oct 06 18:42:55[  ServiceDispatcher.java:381:ERROR]
---- exception report  
----------------------------------------------------------
Could not commit transaction
Exception: org.ofbiz.entity.transaction.GenericTransactionException
Message: Roll back error, could not commit transaction, was rolled  
back instead (null)
---- stack trace  
---------------------------------------------------------------
org.ofbiz.entity.transaction.GenericTransactionException: Roll back  
error, could not commit transaction, was rolled back instead (null)
org.ofbiz.entity.transaction.TransactionUtil.commit
(TransactionUtil.java:177)
org.ofbiz.entity.transaction.TransactionUtil.commit
(TransactionUtil.java:152)

However, then the service which is catching it will also throw a  
service exception:
Service [xxx] threw an unexpected exception/error
Exception: org.ofbiz.service.GenericServiceException
Message: Commit transaction failed
---- stack trace  
---------------------------------------------------------------
org.ofbiz.service.GenericServiceException: Commit transaction failed
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:382)
org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:194)
org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:122)

so the net result is that even if the first service is set to use-
transaction="false" and the second one is specifically designed just  
to log an error, it still fails.


On Oct 20, 2006, at 3:28 PM, David E Jones wrote:

>
> A rollback, or a setRollbackOnly?
>
> -David
>
>
> On Oct 20, 2006, at 4:14 PM, Si Chen wrote:
>
>> Has anybody noticed this?  It seems sometimes when use-
>> transaction="false" we're still getting a rollback when a service  
>> returns an error.
>>
>> Si
>> [hidden email]
>>
>>
>>

Best Regards,

Si
[hidden email]

[David E Jones-2]

Si,

To narrow down where the rollback only flag is actually set you  
should be able to see a stack trace for that in the logs. It may be  
in the service engine code, but the entity engine also does this sort  
of thing in certain cases.

What you're describing sounds like very normal behavior though. If  
there is an error, then the transaction should be rolled back, or if  
the code didn't begin the transaction then it should be marked  
rollback only.

Not doing things that way would cause an awful lot of problems....

What is it you are trying to do that would not follow this pattern?

You would almost never want something to ignore errors and commit  
anyway. If you want to have certain things committed or rolled back  
independent of other things, they should go in a separate service  
that has require-new-transaction=true.

If you have a service that doesn't do database operations but might  
return success or failure, then have it return fail instead of error.

-David


On Oct 20, 2006, at 7:45 PM, Si Chen wrote:

> David,
>
> It is a setRollBackOnly, kind of like this:
> 20 Oct 06 18:42:55[    TransactionUtil.java:247:INFO ]  
> [TransactionUtil.setRollbackOnly] transaction roll back only set
> 20 Oct 06 18:42:55[  ServiceDispatcher.java:381:ERROR]
> ---- exception report  
> ----------------------------------------------------------
> Could not commit transaction
> Exception: org.ofbiz.entity.transaction.GenericTransactionException
> Message: Roll back error, could not commit transaction, was rolled  
> back instead (null)
> ---- stack trace  
> ---------------------------------------------------------------
> org.ofbiz.entity.transaction.GenericTransactionException: Roll back  
> error, could not commit transaction, was rolled back instead (null)
> org.ofbiz.entity.transaction.TransactionUtil.commit
> (TransactionUtil.java:177)
> org.ofbiz.entity.transaction.TransactionUtil.commit
> (TransactionUtil.java:152)
>
> However, then the service which is catching it will also throw a  
> service exception:
> Service [xxx] threw an unexpected exception/error
> Exception: org.ofbiz.service.GenericServiceException
> Message: Commit transaction failed
> ---- stack trace  
> ---------------------------------------------------------------
> org.ofbiz.service.GenericServiceException: Commit transaction failed
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:
> 382)
> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:
> 194)
> org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:
> 122)
>
> so the net result is that even if the first service is set to use-
> transaction="false" and the second one is specifically designed  
> just to log an error, it still fails.
>
>
> On Oct 20, 2006, at 3:28 PM, David E Jones wrote:
>
>>
>> A rollback, or a setRollbackOnly?
>>
>> -David
>>
>>
>> On Oct 20, 2006, at 4:14 PM, Si Chen wrote:
>>
>>> Has anybody noticed this?  It seems sometimes when use-
>>> transaction="false" we're still getting a rollback when a service  
>>> returns an error.
>>>
>>> Si
>>> [hidden email]
>>>
>>>
>>>
>
> Best Regards,
>
> Si
> [hidden email]
>
>
>

[Si Chen-2]

David,

I think that is the problem I'm noticing.  There is a  
calcShipmentEstimate service which returns an error if no shipment  
estimates can be found, and it crashes the entire update order item  
service when you try to modify orders.  I think it should probably be  
returning a fail instead?

On Oct 22, 2006, at 9:06 PM, David E Jones wrote:

>
> Si,
>
> To narrow down where the rollback only flag is actually set you  
> should be able to see a stack trace for that in the logs. It may be  
> in the service engine code, but the entity engine also does this  
> sort of thing in certain cases.
>
> What you're describing sounds like very normal behavior though. If  
> there is an error, then the transaction should be rolled back, or  
> if the code didn't begin the transaction then it should be marked  
> rollback only.
>
> Not doing things that way would cause an awful lot of problems....
>
> What is it you are trying to do that would not follow this pattern?
>
> You would almost never want something to ignore errors and commit  
> anyway. If you want to have certain things committed or rolled back  
> independent of other things, they should go in a separate service  
> that has require-new-transaction=true.
>
> If you have a service that doesn't do database operations but might  
> return success or failure, then have it return fail instead of error.
>
> -David
>
>
> On Oct 20, 2006, at 7:45 PM, Si Chen wrote:
>
>> David,
>>
>> It is a setRollBackOnly, kind of like this:
>> 20 Oct 06 18:42:55[    TransactionUtil.java:247:INFO ]  
>> [TransactionUtil.setRollbackOnly] transaction roll back only set
>> 20 Oct 06 18:42:55[  ServiceDispatcher.java:381:ERROR]
>> ---- exception report  
>> ----------------------------------------------------------
>> Could not commit transaction
>> Exception: org.ofbiz.entity.transaction.GenericTransactionException
>> Message: Roll back error, could not commit transaction, was rolled  
>> back instead (null)
>> ---- stack trace  
>> ---------------------------------------------------------------
>> org.ofbiz.entity.transaction.GenericTransactionException: Roll  
>> back error, could not commit transaction, was rolled back instead  
>> (null)
>> org.ofbiz.entity.transaction.TransactionUtil.commit
>> (TransactionUtil.java:177)
>> org.ofbiz.entity.transaction.TransactionUtil.commit
>> (TransactionUtil.java:152)
>>
>> However, then the service which is catching it will also throw a  
>> service exception:
>> Service [xxx] threw an unexpected exception/error
>> Exception: org.ofbiz.service.GenericServiceException
>> Message: Commit transaction failed
>> ---- stack trace  
>> ---------------------------------------------------------------
>> org.ofbiz.service.GenericServiceException: Commit transaction failed
>> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:
>> 382)
>> org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:
>> 194)
>> org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:
>> 122)
>>
>> so the net result is that even if the first service is set to use-
>> transaction="false" and the second one is specifically designed  
>> just to log an error, it still fails.
>>
>>
>> On Oct 20, 2006, at 3:28 PM, David E Jones wrote:
>>
>>>
>>> A rollback, or a setRollbackOnly?
>>>
>>> -David
>>>
>>>
>>> On Oct 20, 2006, at 4:14 PM, Si Chen wrote:
>>>
>>>> Has anybody noticed this?  It seems sometimes when use-
>>>> transaction="false" we're still getting a rollback when a  
>>>> service returns an error.
>>>>
>>>> Si
>>>> [hidden email]
>>>>
>>>>
>>>>
>>
>> Best Regards,
>>
>> Si
>> [hidden email]
>>
>>
>>

Best Regards,

Si
[hidden email]

[David E Jones-2]

The best solution is probably to improve the behavior of the  
calcShipmentEstimate service so that it doesn't return error if there  
are no shipment estimates. It sounds like what you're saying is that  
having no shipment estimates isn't really an error condition, which I  
totally agree with so this service should not be returning an error  
in that case.

-David


On Oct 24, 2006, at 5:52 PM, Si Chen wrote:

> David,
>
> I think that is the problem I'm noticing.  There is a  
> calcShipmentEstimate service which returns an error if no shipment  
> estimates can be found, and it crashes the entire update order item  
> service when you try to modify orders.  I think it should probably  
> be returning a fail instead?
>
> On Oct 22, 2006, at 9:06 PM, David E Jones wrote:
>
>>
>> Si,
>>
>> To narrow down where the rollback only flag is actually set you  
>> should be able to see a stack trace for that in the logs. It may  
>> be in the service engine code, but the entity engine also does  
>> this sort of thing in certain cases.
>>
>> What you're describing sounds like very normal behavior though. If  
>> there is an error, then the transaction should be rolled back, or  
>> if the code didn't begin the transaction then it should be marked  
>> rollback only.
>>
>> Not doing things that way would cause an awful lot of problems....
>>
>> What is it you are trying to do that would not follow this pattern?
>>
>> You would almost never want something to ignore errors and commit  
>> anyway. If you want to have certain things committed or rolled  
>> back independent of other things, they should go in a separate  
>> service that has require-new-transaction=true.
>>
>> If you have a service that doesn't do database operations but  
>> might return success or failure, then have it return fail instead  
>> of error.
>>
>> -David
>>
>>
>> On Oct 20, 2006, at 7:45 PM, Si Chen wrote:
>>
>>> David,
>>>
>>> It is a setRollBackOnly, kind of like this:
>>> 20 Oct 06 18:42:55[    TransactionUtil.java:247:INFO ]  
>>> [TransactionUtil.setRollbackOnly] transaction roll back only set
>>> 20 Oct 06 18:42:55[  ServiceDispatcher.java:381:ERROR]
>>> ---- exception report  
>>> ----------------------------------------------------------
>>> Could not commit transaction
>>> Exception: org.ofbiz.entity.transaction.GenericTransactionException
>>> Message: Roll back error, could not commit transaction, was  
>>> rolled back instead (null)
>>> ---- stack trace  
>>> ---------------------------------------------------------------
>>> org.ofbiz.entity.transaction.GenericTransactionException: Roll  
>>> back error, could not commit transaction, was rolled back instead  
>>> (null)
>>> org.ofbiz.entity.transaction.TransactionUtil.commit
>>> (TransactionUtil.java:177)
>>> org.ofbiz.entity.transaction.TransactionUtil.commit
>>> (TransactionUtil.java:152)
>>>
>>> However, then the service which is catching it will also throw a  
>>> service exception:
>>> Service [xxx] threw an unexpected exception/error
>>> Exception: org.ofbiz.service.GenericServiceException
>>> Message: Commit transaction failed
>>> ---- stack trace  
>>> ---------------------------------------------------------------
>>> org.ofbiz.service.GenericServiceException: Commit transaction failed
>>> org.ofbiz.service.ServiceDispatcher.runSync
>>> (ServiceDispatcher.java:382)
>>> org.ofbiz.service.ServiceDispatcher.runSync
>>> (ServiceDispatcher.java:194)
>>> org.ofbiz.service.GenericDispatcher.runSync
>>> (GenericDispatcher.java:122)
>>>
>>> so the net result is that even if the first service is set to use-
>>> transaction="false" and the second one is specifically designed  
>>> just to log an error, it still fails.
>>>
>>>
>>> On Oct 20, 2006, at 3:28 PM, David E Jones wrote:
>>>
>>>>
>>>> A rollback, or a setRollbackOnly?
>>>>
>>>> -David
>>>>
>>>>
>>>> On Oct 20, 2006, at 4:14 PM, Si Chen wrote:
>>>>
>>>>> Has anybody noticed this?  It seems sometimes when use-
>>>>> transaction="false" we're still getting a rollback when a  
>>>>> service returns an error.
>>>>>
>>>>> Si
>>>>> [hidden email]
>>>>>
>>>>>
>>>>>
>>>
>>> Best Regards,
>>>
>>> Si
>>> [hidden email]
>>>
>>>
>>>
>
> Best Regards,
>
> Si
> [hidden email]
>
>
>