1.5. Common errors

1.5.1. When using application identity, what can cause strange behavior like objects not being found?
1.5.2. What causes connection errors when returning persistent instances from a session bean?
1.5.3. Why do my relations get lost after I commit?
1.5.1.

When using application identity, what can cause strange behavior like objects not being found?

The most common cause of problems like these when using application identity is failure for the application identity class to properly override the equals and hashCode methods so that identity objects with equivalent primary key values are considered equal.

1.5.2.

What causes connection errors when returning persistent instances from a session bean?

A common cause of this problem is due to the EJB container serializing the instances that are being returned from the EJB. The serialization process happens at a point in the EJB lifecycle where the current status of the transaction is undefined. Since serialization may result in unloaded relations being traversed, Kodo will try to obtain a JDBC Connection to perform the traversal, and the application server may then disallow the connection access due to an invalid transaction status. The simplest solution to this is to either make the object to be returned transient, or return a detached instance, or manually perform the serialization before returning from the EJB method.

1.5.3.

Why do my relations get lost after I commit?

The problem may be that you have defined a bidirectional relation, but you did not set both sides of the relation. Kodo does not perform any "magic" to keep relations consistent by default; the application must always ensure that the Java object model is consistent. You can, however, configure Kodo to manage bidirectional relations for you as described in Section 5.4, “Managed Inverses”.

 

Skip navigation bar   Back to Top