ServiceXaWrapper is very very stupid and broken

[Eilebrecht, Karl (Key-Work)]

Hi Adam,

>>  This effectively makes *all* registered
>> services async.  That's just broken.
Obviously the rollback service simply cannot run within the same transaction. Otherwise it was affected by the proceeding rollback itself.
Thus a rollback service will never "see any changes that never happened" (rollback) because it runs in another transaction. That's the idea behind READ_COMMITTED (most of you will use this isolation mode). However, the idea behind a rollback service I think is cleaning up / housekeeping. Imagine services that use short single transactions or other async+wait service calls inside. Thus it can happen, that there is some rubbish left in the database even after a successful rollback (call it temporary soft inconsistency). For performance reasons it can be better to have an async cleanup/consistency service that runs separately than trying to make the service itself perfect in case of rollback. I just saw that piece of code the first time, but I think it could be a good idea to have an option that forces the service currently being rolled back to wait for the rollback sync(!) service. By the way: inside the rollback service you could suspend the current transaction. That disconnects you from isolation level and most databases should let you see all the changes made before by other transactions - even the ones not committed. This may or may not be helpful.
I think the thread change you mentioned may be related to a problem in TransactionUtil I stumbled across years ago (see also https://issues.apache.org/jira/browse/OFBIZ-1029). At that time TransactionUtil was unable to suspend a transaction that was marked for rollback before. Probably this bug still exists and leads to the situation that you cannot change the transaction of the active thread temporarily (i.e. to persist a message or doing other persistent things), if the current transaction is already marked for rollback. To change the thread is the "rough" way to get rid of the transaction.
Having fixed that, the rollback service could then be executed within the same thread (no need for a new thread), of course still in its own new transaction especially NOT "seeing" changed data from the transaction currently being rolled back.

>> One thing I'm not familiar with, is if a thread that spawns a new one
>> automatically inherits the parent thread's transaction.
No.

>> Now comes the time to actually run the real service.  Since the
>> service is always an async service, it'll be serialized to JobSandbox,
>> and run a very short time later.  Not immediately.
I think the service itself must handle this problem in another way (try/catch etc.).

>> But, the service never has a
>> chance of succeeding, so this will repeating ad infinitum.
I'm not so familiar with the job scheduler, but a colleague told me, there is some option to give up after n attempts. This may help you with the pollution problem.

>> Does anyone else agree with my reading of the code?  Just looking at
>> the source I was able to discover these very poorly implemented designs.
>> Does anyone else agree with my reading here?
There is always something to do in a big house. Broken boiler, cables not where expected, loft conversion to be done. Keep cool! ;-)


Regards.
Karl




Karl Eilebrecht
Key-Work Consulting GmbH | Kriegsstr. 100 | 76133 Karlsruhe | Germany | www.key-work.de
Fon: [phone] | E-Mail: [hidden email] | Fax: [phone]

Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim
Gesch?ftsf?hrer: Andreas Stappert, Tobin Wotring