While working at this issue I found that we introduced a problem by commiting
CASTOR-1173. The problem apears if you call db.getDatabase() multipl times on the same JDOManager instance as transaction manager will be set to null at second and following calls. If included a quick fix with the patch that i don't want to commit with this patch but want to resolve when working at CASTOR-1179.
In addition I found a problem in SQLEngine that caused the ArrayIndexOutOfBoundException to be thrown. The reason was that we checked field.length instead of _field.length (take care on the underline) in the for loop to find the fields that caused the update to fail.
After all that I got to the real problem which has been how we handle conversion of char or string values in database to boolean properties in persistent objects. Pre patch we always returned a boolean value even if the database contained a value which does not conform to the rules defined. This behaviour caused that we could load records with wrong values without problems but got a ObjectModifiedException when we tried to update these values as our update statment includes checking of all old values in the where clause of SQL statement.
With the patch this behavier changes to strict checking if the loaded char/string value matches one of the boolean characters defined by conversion rule. If the values does not match a ClassCastException explaing the fail rason will be thrown.
Having said that this change is quite critical as it changes castors default load behavior for boolean values which may cause some users to see exceptions haven't seen with previous releases. Thinking about the pro's and con's of the patch I agree with Nick that it would be better to see that there is a problem at load instead of commit time.
Before commiting this I like to here some other opinons first. But be aware that time to next release is quite short