DB Adapter polling and logical delete: Process succeed but lock on database

Question

We have the following busisness flow, that reseult in a BPEL behaviour we did not expect. I hope that some of you had the same exeprience.
The database adpater polls from a table new records based on a value (20) in a status field. When it finds records, it will process them and update the status field (20 -> 30).
When we update from sqlplus a record, select for update on record with status 20, then We see in the logging that the update fails, but the process ran sucessfully. At the database we see an outstanding lock. If we commit the sqlplus session (after a few minutes), the status field is updated to 30.
This is strange to me, the BPEL process was already sucessfully finished.
Anyone seen this behaviour?
Regards,
Marc
The logging
<2006-05-02 13:06:37,052> <DEBUG> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.TopLinkLogger log> SELECT STATUS,
USERID FROM AQADM.TEST_UPDATE_VANUIT_BPEL WHERE ((STATUS = ?) AND ((STATUS <> ?) OR (STATUS IS NULL)))
/ORA-
<2006-05-02 12:03:21,473> <DEBUG> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Delivery Thread 'JCA-work-instance:Database Adapter-0 pe
rforming unsynchronized post() to localhost
<2006-05-02 12:03:21,879> <DEBUG> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.TopLinkLogger log> begin transact
ion
<2006-05-02 12:03:21,881> <DEBUG> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.TopLinkLogger log> UPDATE PROV.PR
OV_USER_ACCOUNT SET STATUS_CMMAC = ? WHERE (PUAT_ID = ?)
bind => [30, 81600]
<2006-05-02 12:03:22,188> <WARN> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.InboundWork runOnce> Exception dur
ing polling of the database ORABPEL-11624
DBActivationSpec Polling Exception.
Query name: [prov_cmmac], Descriptor name: [PROVprocessmacaddress.ProvUserAccount]. Polling the database for events failed on this iteration.
If the cause is something like a database being down successful polling will resume once conditions change. Caused by Exception [TOPLINK-4002] (OracleAS
TopLink - 10g (9.0.4.5) (Build 040930)): oracle.toplink.exceptions.DatabaseException
Exception Description: java.sql.SQLException: ORA-20220: MDB3 ERR: session not in admin mode
ORA-06512: at "PROV.PUAT_BUR", line 90
ORA-04088: error during execution of trigger 'PROV.PUAT_BUR'

Answer 1

The following entry:
<MESSAGE>
<HEADER>
<TSTZ_ORIGINATING>2008-12-11T17:50:20.119+01:00</TSTZ_ORIGINATING>
<COMPONENT_ID>tip</COMPONENT_ID>
<MSG_TYPE TYPE="TRACE"></MSG_TYPE>
<MSG_LEVEL>16</MSG_LEVEL>
<HOST_ID>u514603.cmcdev.be</HOST_ID>
<HOST_NWADDR>10.151.70.3</HOST_NWADDR>
<MODULE_ID>esb.server.service.impl.inadapter</MODULE_ID>
<THREAD_ID>18</THREAD_ID>
<USER_ID>orasoad</USER_ID>
</HEADER>
<CORRELATION_DATA>
<EXEC_CONTEXT_ID><UNIQUE_ID>10.151.70.3:11323:1229014220014:8</UNIQUE_ID><SEQ>0</SEQ></EXEC_CONTEXT_ID>
</CORRELATION_DATA>
<PAYLOAD>
<MSG_TEXT>JCA: &lt;oracle.tip.adapter.db.TopLinkLogger log> SELECT UNIQUE_SUPPLIER_ID, SUPPLIER_NAME, SUPPLIER_NUMBER, NUMBER_TYPE, CM_SUPPLIER_TYPE, VAT_REGISTRATION_NUM, M_NUMBER, ADM_ID, OFB_PARTY_ID, CENTURY, LANGUAGE, ATTRIBUTE_CATEGORY, SPARE6, SPARE8, SPARE9, SPARE10, SPARE11, SPARE12, SPARE13, SPARE14, SPARE15, STATUS, ERROR_CODE, FILE_ID FROM XXCM.XXCM_AP_SUPPLIERS WHERE (STATUS = ?) ORDER BY UNIQUE_SUPPLIER_ID ASC FOR UPDATE NOWAIT
     bind => [MINE[undef:instance]]
</MSG_TEXT>
</PAYLOAD>
</MESSAGE>
can be found in $ORACLE_HOME/j2ee/oc4j_soa/log/oc4j_soa_default_group_1/oc4j/*.xml
Regards