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
[EMAIL PROTECTED]
Best Regards,
Si
[EMAIL PROTECTED]
Best Regards,
Si
[EMAIL PROTECTED]
