Deploying BC4J 9.0.3.4 Application in WebSphere 5.0.2

Question

We are deploying the application developed using BC4J 9.0.3.4 libraries in WebSphere 5.0.2.
We are getting the following error when we tried to create new row using BC4J view object.
[511] BaseSQLBuilder: setSavepoint 'BO_SP' ignored
[512] BaseSQLBuilder Executing DML ... (Insert)
[513] Executing DML...
[514] Warning: BaseSQLBuilder does not support RETURNING (key-cols) clause....
[515] Warning: BaseSQLBuilder does not support RETURNING (cols) clause....
[516] INSERT INTO FISTS_USER_MESSAGE(MSG_ID,MSG_FROM_USER_ID,MSG_MOD_NAME,MSG_SUBJECT,
MSG_BODY,MSG_CREATE_TS,MSG_USER_ID,MSG_GLOBAL_FLAG,MSG_EXPIRATION_DT) VALUES (?,?,?,?,?,?,?,?,?)
[517] Fetch RefreshOnInsert attributes
[518] BaseSQLBuilder.doRefreshSQL, Executing Select for Refresh-on-insert or update attributes
[519] Warning: Attempting to use current primary key attributes for refresh SQL.
[520] ******* Found no UniqueKey attribute when a PK attribute is marked for refresh on Entity:FistsUserMessage
[521] Built select: 'SELECT MSG_ID, MSG_GLOBAL_FLAG FROM FISTS_USER_MESSAGE'
[522] Executing Refresh SQL...SELECT MSG_ID, MSG_GLOBAL_FLAG FROM FISTS_USER_MESSAGE WHERE MSG_ID=?
[523] General failure Failure in select : JBO-25019: Entity row of key oracle.jbo.Key[-42 ] not found in FistsUserMessage.
[524] Close prepared statement for refresh SQL
[525] BaseSQLBuilder: rollbackToSavepoint 'BO_SP' ignored
oracle.jbo.RowAlreadyDeletedException: JBO-25019: Entity row of key oracle.jbo.Key[-42 ] not found in FistsUserMessage.
FYI: we are using BC4J setting jbo.SQLBuilder=SQL92, since jbo.SQLBuilder=Oracle is not working either.
====================================================
Error when we use BC4J setting jbo.SQLBuilder=Oracle
java.lang.ClassCastException: com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement
     at oracle.jbo.server.OracleSQLBuilderImpl.doStatementSetRowPrefetch(OracleSQLBuilderImpl.java:919)
Any help to resolve this issue is appreciated.
Sam

Answer 1

Since you're using WebSphere, SQLBuilder=SQL92 is the correct setting.
As for your RowAlreadyDeletedException, the following lines are key in solving your issue:
[519] Warning: Attempting to use current primary key attributes for refresh SQL.
[520] ******* Found no UniqueKey attribute when a PK attribute is marked for refresh on Entity:FistsUserMessageIt seems
1. You designated your PK as DBSequence which implies/needs retrieve-on-insert. (Retrieve-on-insert means that after the row is inserted into db, the attr value needs to be refreshed from database).
With DBSequence, when you create a new row, the DBSequence domain object is assigned a temporary value (in your case -42).
2. You are using a SQLBuilder which does not support 'RETURNING' clause. Oracle DB allows you do insert a row and then bring back the attr values using the RETURNING clause. Since your SQLBuilder does not support RETURNING, BC4J generates a SQL block that has
-> The INSERT statement
-> Immediately followed by a SELECT statement that tries to retrieve your PK attr.
3. For this SELECT statement, we need a WHERE clause to identify the row that was just inserted. Normally (if the PK attr is stable), we use the PK attr. However, in your case, since PK itself will be assigned a new value in the database, we try to find another unique attribute. When this turn up nothing we print the above "Warning: Attempting to ..."
4. Then, it issues SELECT statement with WHERE MSG_ID = -42. Since database assigned a new value to this attr, it doesn't find the row.
5. So, it thinks that the row was deleted by another transaction ==> RowAlreadyDeletedException.
~~~~~
To work around this, I would suggest one of the followings:
A) Instead of DBSequence and retrieve-on-insert, you can try to set the PK value by getting its seq number in the EntityImpl's create() method override.
B) Or, you can desginate some other attr (if you have one) as unique (should be stable, meaning that its value will not change by the insert operation). Then, we can use that to locate the row and perform the correct SELECT operation.
Thanks.
Sung