I'm facing strange behaviour with long raw fields mapped as
BLOBS in JAWS...
It seems that while initializing any transaction the cache value for these fields are setted on the database.
This is the opposite of what I could think (Am I Wrong ?).
My tests just show me this behaviour for the long raw fields. All other field types seem to work nice...(just using VARCHAR(n) for other fields).
Has someone encountered similar problems ?
Transaction commit option setted to C in the jaws.xml file. The cache is a LRU one (I don't know if it matters). This cache & commit option are defined for all my CMP entity beans...
Oracle 126.96.36.199 using the Oracle "thin" (very huge indeed) driver.
Using a JDBC client we set a value in the long raw field
that 's committed. SQL+ show us the right value.
Now launching our client (an IDE like for a proprietray environment), a getFoo() method is invoked, starting a transaction, then setting to the DB the previous byte
. The new value is lost...
After a change to my deployment descriptor I removed all
transaction starters, so now a getFoo() does not start any transaction, with this commit option, I have no more
any writing for the LONG RAW field, but the read value is the previous one not the one setted with the JDBC client.
Restarting JBoss (or a new deployment) and we can watch the expected value...
Am I loosing something or is there some strange underlying mechanism ?
Any help or clue welcomed