0 Replies Latest reply on Feb 27, 2002 4:06 AM by jmoliere

    Long Raw fields & cache with JBoss 2.4.4 - CMP entities

    jmoliere

      Hi all,
      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 ?

      Details:
      Jboss 2.4.4
      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 8.1.7.3 using the Oracle "thin" (very huge indeed) driver.

      Test procedure:
      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
      Cheers
      jerome