Stale data problem

flawlor · **Joined:** Thu Jan 17, 2008 8:58 pm **Posts:** 20

I am having the following problem.

In one browser session I add/update some data. I can see that it has been persisted to the database.

In another session, which was previously opened to the old data I re-do my search, but I see the old data. If I log out and back in the search shows the new data.

From what I have read I suspect that the application is caching the data in the first level cache (session?).

In this application the users must see the latest data so I don't want this caching. What is the correct way to force a DB access on every query?

I have done nothing to specify any caching behavior.

I am running this in an AppFuse 1 environment (which uses Hibernate for the user management - but I don't see any special caching directives).

My Hibernate interfaces were generated by the MyEclipse Hibernate wizard and I don't see any caching directives.

I am not doing anything to explicitly save the query results in the session or elsewhere.

The query which does the key call is:

Code:

String queryString = "from Survivor as model where model.survivorCode=? and model.clinic.clinicId=?";
Query queryObject = getSession().createQuery(queryString);
queryObject.setParameter(0, survivorCode);
queryObject.setParameter(1, clinicId);
return queryObject.list();

Thanks for any help.

farzad · **Posted:** Fri Feb 29, 2008 12:53 pm

With HQL queries you shouldn't have this problem is the query cache is disabled. however, you may try a few things:

1- Call session.clear() prior to the query.
2- Explicitly set the query cache to false for the query.
3- Check the transaction isolation level. You might need a READ_UNCOMMITED isolation level.

Farzad-

flawlor · **Joined:** Thu Jan 17, 2008 8:58 pm **Posts:** 20

farzad,

Thanks for the quick response.

I added session.clear() and queryObject.setCacheable(false) and based upon a quck test, this seems to have done the trick (cross fingers).

I have some questions, however.

I could not find any reference in the book about how to set the query cache to false. Did you mean queryObject.setCacheable(false)?

I didn't find anyplace in my app setting the isolation level (hibernate.connection.isolation?). Is there a way to query this at run time to be sure of its setting? (JDBC level?)

Thanks again for your help.
-- Frank

farzad · **Posted:** Fri Feb 29, 2008 2:53 pm

flawlor wrote:

I could not find any reference in the book about how to set the query cache to false. Did you mean queryObject.setCacheable(false)?

I didn't find anyplace in my app setting the isolation level (hibernate.connection.isolation?). Is there a way to query this at run time to be sure of its setting? (JDBC level?)

setCacheable is good. For isolation level you usually set it on a datasource if you are using any or a connection pool. Since hibernate comes with a c3p0 connection pool you also can set it in hibernate if you are using c3p0.

I am a little concerned though that session.clear made a difference. You may go ahead and do a test with only setCacheable(false) and see if that makes a difference. I was hoping more for the isolation level to solve your problem.

Farzad-

flawlor · **Joined:** Thu Jan 17, 2008 8:58 pm **Posts:** 20

Your guess was right on.

I only needed the setCacheable(false)

flawlor · **Joined:** Thu Jan 17, 2008 8:58 pm **Posts:** 20

This problem seems to extend a little deeper than I though.

I am finding that even the user who is editing the data is having a problem with getting stale data.

Basically I have 3 objects: Patient, Treatment, Treatment Detail.

The problem I am seeing is that if the user changes the Treatment Details for a Treatment (I delete all the old Treatment Details and add new Treatment Details) and then re-finds the patient, they are seeing the old Treatment Details.

I assume this is because the old Treatment Details are cached in the session from the original find. This is probably because the serch finds the patient which has a list of Treatments which each have a list of Treatment Details. BUT, when I do the update I have not hung on to these objects in the code, but just do a search on the Treatment ID needing update, update its Treatment Details list and save.

Apparently Hibernate doesn't know that this has outdated the original structure of objects under the patient (I would have thought it had unique IDs for objects).

What is the right way to solve this problem?

I have queryObject.setCacheable(false) on the patient search, which does seem to get a fresh copy of the patient data, but not the Treatment and Treatment Details.

Is there some way to force this non-caching recursively? (all the access code was automatically generated and I don't really want to have to touch it).

Or, to do the Treatment Details update should I hang onto refernces to to the original Hibernate objects and update and save them? Does this require me to "re-attach" them or something?

Or ???

Thanks,

-- Frank

flawlor · **Joined:** Thu Jan 17, 2008 8:58 pm **Posts:** 20

I have tried the following without success:

session.setCacheMode(CacheMode.REFRESH);

created my own Treatment finder which does

queryObject.setCacheable(false);

but I am seill getting the old TreatmentDetails.

Maybe the problem is that when it lazily fetches the TreatmentDetails it is still using the cache????

How can I prevent that?

farzad · **Posted:** Mon Mar 03, 2008 8:11 pm

I am wondering if you have a second level cache. In any events you may want to try fetch joins so that associations are also forced to be retrieved from database. However, it is not a bad idea to find why this happens to you even though if fetch joins solve your problem. I have a feeling this problem will get you again.

Farzad-

flawlor · **Joined:** Thu Jan 17, 2008 8:58 pm **Posts:** 20

I don't have a second level cache.

I seem to have solved the problem by keeping a reference to the original Hibernate objects, updating and saving them.

It is necessary to re-attach them (update).

It still concerns me that re-fetching a new hibernate object and doing the update on that leaves the same logical objects in the first level cache in a stale state.

This app is small enough that I can know what might have been fetched, but I have also worked on many large apps involving many developers where this would be very difficult to understand and controll.

This makes me concerned about the scalability of Hibernate.

I also found, by accident, that if I failed to re-attach (update) the patient object, but did re-attach the treatment and treatment details, then when I saved Hibernate created a NEW patient entry in the database with a new key and pointed the updated treatment to the new patient record!!!!

Since the patient object has an ID in it already I'm amazed that it would go and create a new patient entry with a different ID.

farzad · **Posted:** Wed Mar 05, 2008 8:27 pm

Show me the mappings and a test code that has the stale problem.

Farzad-

flawlor · **Joined:** Thu Jan 17, 2008 8:58 pm **Posts:** 20

Here is the basic overview of what I think is happening.
I can provide more detail wherever you need it.

The application has three tables/object types of interest here:
- Patient
- Treatment (foreign key to patient) - 0 to N per patient
- TreatmentDetail (foreign key to Treatment) - N per Treatment

All the objects and hibernate code are vanilla objects and standard hibernate code automatically generated by MyEclipse hibernate wizard.

When the user selects the patient the app retrieves and shows all the treatments and details ("Patient find").
The app didn't used to (but now does) hang onto a reference to the Hibernate Patient object.

If the user edits a treatment, the application used to do a new query to the database (based upon treatment ID) to get the "old" treatment and details ("Treatment find").
The old details were deleted and new ones created based upon the changes.
The treatment and details were saved.
The database shows the updated treatment and new detail records. The old detail records are gone.

If the user repeated the above process (find patient, update treatment) the application was throwing an error.
Having hibernate print out the query parms showed that on the second sequence the treatment was again trying to delete the original treatment detail records again, not the ones created by the first update!!

The fix (which seems to have worked) was to hang onto the original collection of patient objects, update the appropriate treatment and save it.

What I suspect was happening was that the original collection of objects was being held in the 1st level cached.
When I did the isolated treatment update is was NOT updating the corresponding treatment object in the patient collection.
When the application did the second "treatment find" for the second update it was somehow finding the old data - maybe from the patient collection in the 1st level cache rather than getting the updated data from the database.
Apparently is was not finding the updated treatment object for whatever reason.

I don't know what semantics hibernate tries to achieve, but it seems very dangerous to keep the treatment with the old details cached and not update it when the update code saves the updated treatment.

Here, in brief are the old code seqences:

Code:

"Find Patient"
  String queryString = "from Patient as model where model.patientCode=?";
  Session session = getSession();
  Query queryObject = session.createQuery(queryString);
  queryObject.setParameter(0, patientCode);
  patient = queryObject.list().get(0);
 
"Update Treatment"
  session = HibernateSessionFactory.getSession();
  tx = session.beginTransaction();
  treatment = new TreatmentDAO_().findById(treatmentId, session);  // ** this is returning OLD data **
  // delete existing detail values
  // add & save new details values
  session.save( treatment );
  session.flush(); // ** throws error here on second update **
  tx.commit();

tharrisx · **Posted:** Sat Mar 15, 2008 4:53 pm

I suspect you and I are having the same issue. Can you post or send me your stack trace? Is it a StaleObjectStateException?

Here's the relevant portion of a stack trace from our logs resulting from a get our pojo from Hibernate:

Code:

ERROR [http-80-5] (AbstractFlushingEventListener.performExecutions:301) Could not synchronize database state with session
org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.sourcemedia.webpub.cms.model.content.Quiz#544631]
        at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1765)
        at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2407)
        at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307)
        at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607)
        at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92)
        at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
        at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
        at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142)
        at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
        at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
        at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
        at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
        at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
        at com.sourcemedia.commons.entity.AbstractSessionHandler.perform(AbstractSessionHandler.java:64)

Hibernate Core 3.2.6, Annotations 3.3.0, EntityManager 3.3.1

Tom

flawlor · **Joined:** Thu Jan 17, 2008 8:58 pm **Posts:** 20

Your error is different.

In my case it gave an error which said something like "tried to update one row but only updated 0".

The "update" was actually its attemp to again delete the old detail item which was already deleted rather than the newer one.

farzad · **Posted:** Sun Mar 16, 2008 7:51 pm

This tells me you are trying to manipulate something that hibernate already does. Show me the mapping between Treatment and TreatmentDetail. Also give me the following lines:

Code:

// delete existing detail values
  // add & save new details values 

The sql outputs before exception will also help.

Farzad-

flawlor · **Joined:** Thu Jan 17, 2008 8:58 pm **Posts:** 20

Code:

// This is the current code, which seems to work OK.

// mappings - the treatment detail records are actually called FactorValues

<hibernate-mapping>
    <class name="org.laf.ccs.persistence.Treatment" table="r_treatment" catalog="ccsphs">
        <id name="treatmentId" type="java.lang.Long">
            <column name="TREATMENT_ID" />
            <generator class="native" />
        </id>
        [ Treatment fields ... ] 
        <set name="factorValues" inverse="true">
            <key>
                <column name="TREATMENT_ID" not-null="true" />
            </key>
            <one-to-many class="org.laf.ccs.persistence.FactorValue" />
        </set>
    </class>
</hibernate-mapping>

<hibernate-mapping>
    <class name="org.laf.ccs.persistence.FactorValue" table="r_factor_value" catalog="ccsphs">
        <id name="factorValueId" type="java.lang.Long">
            <column name="FACTOR_VALUE_ID" />
            <generator class="native" />
        </id>
        <many-to-one name="treatment" class="org.laf.ccs.persistence.Treatment" fetch="select">
            <column name="TREATMENT_ID" not-null="true" />
        </many-to-one>
        [ FactorVaue fields ... ]
    </class>
</hibernate-mapping>


// update code

// Delete old treatment values
for (FactorValue factorValue : treatment.getFactorValues()) {
        session.update(factorValue);  // re-attach
        session.delete( factorValue );         
}
// add new treatment values
Set<FactorValue> factorValues = // code to create new FactorValues;
treatment.setFactorValues(factorValues);
session.save( treatment );
for (FactorValue factorValue : factorValues) session.save( factorValue );


// Runtime SQL

Note that the old FactorValues being deleted have IDs 17-24.
The code first does an update (!!!!!) and then deletes these.
The new FactorValues have IDs 25-31 and are the only remaining ones in the DB after the operation, as expected.
For some reason the code first creates the new FactorValues.

[CCS_R1] INFO [http-8080-Processor23] Util.incidentToTreatment(39) | NewTreatmentController.onSubmit: treatmentId=1
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | insert into ccsphs.r_factor_value (TREATMENT_ID, FACTORSTRINGID, FLOAT_VALUE, DATE_VALUE, FACTOR_ID) values (?, ?, ?, ?, ?)
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '2015' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(80) | binding '22.0' to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '5' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | insert into ccsphs.r_factor_value (TREATMENT_ID, FACTORSTRINGID, FLOAT_VALUE, DATE_VALUE, FACTOR_ID) values (?, ?, ?, ?, ?)
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '5007' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(73) | binding null to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '4' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | insert into ccsphs.r_factor_value (TREATMENT_ID, FACTORSTRINGID, FLOAT_VALUE, DATE_VALUE, FACTOR_ID) values (?, ?, ?, ?, ?)
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '50007' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(73) | binding null to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '3' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | insert into ccsphs.r_factor_value (TREATMENT_ID, FACTORSTRINGID, FLOAT_VALUE, DATE_VALUE, FACTOR_ID) values (?, ?, ?, ?, ?)
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '1' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(73) | binding null to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '1' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | insert into ccsphs.r_factor_value (TREATMENT_ID, FACTORSTRINGID, FLOAT_VALUE, DATE_VALUE, FACTOR_ID) values (?, ?, ?, ?, ?)
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '13' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(73) | binding null to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '10' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | insert into ccsphs.r_factor_value (TREATMENT_ID, FACTORSTRINGID, FLOAT_VALUE, DATE_VALUE, FACTOR_ID) values (?, ?, ?, ?, ?)
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '4005' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(73) | binding null to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '6' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | insert into ccsphs.r_factor_value (TREATMENT_ID, FACTORSTRINGID, FLOAT_VALUE, DATE_VALUE, FACTOR_ID) values (?, ?, ?, ?, ?)
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '12' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(73) | binding null to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '9' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | update ccsphs.r_survivor set CLINIC_ID=?, FIRST_NAME=?, LAST_NAME=?, ADDRESS1=?, ADDRESS2=?, CITY=?, STATE=?, ZIP=?, RELEASE_SIGNED=?, DOCTOR=?, SURVIVOR_STATUS=?, ACTIVE=?, SURVIVOR_CODE=? where SURVIVOR_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '2' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] ByteType.nullSafeSet(80) | binding '1' to parameter: 9
[CCS_R1] DEBUG [http-8080-Processor23] StringType.nullSafeSet(80) | binding 'V' to parameter: 11
[CCS_R1] DEBUG [http-8080-Processor23] ByteType.nullSafeSet(80) | binding '1' to parameter: 12
[CCS_R1] DEBUG [http-8080-Processor23] StringType.nullSafeSet(80) | binding 'FRANK' to parameter: 13
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 14
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | update ccsphs.r_treatment set LAST_UPDATER=?, SURVIVOR_ID=?, CREATED=?, UPDATED=?, TREATMENT_STATUS=? where TREATMENT_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '6' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] TimestampType.nullSafeSet(80) | binding '2008-02-22 11:51:51' to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] TimestampType.nullSafeSet(80) | binding '2008-02-22 11:51:51' to parameter: 4
[CCS_R1] DEBUG [http-8080-Processor23] StringType.nullSafeSet(80) | binding 'V' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 6
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | update ccsphs.r_factor_value set TREATMENT_ID=?, FACTORSTRINGID=?, FLOAT_VALUE=?, DATE_VALUE=?, FACTOR_ID=? where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '13' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(73) | binding null to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '10' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '18' to parameter: 6
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | update ccsphs.r_factor_value set TREATMENT_ID=?, FACTORSTRINGID=?, FLOAT_VALUE=?, DATE_VALUE=?, FACTOR_ID=? where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '50007' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(73) | binding null to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '3' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '17' to parameter: 6
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | update ccsphs.r_factor_value set TREATMENT_ID=?, FACTORSTRINGID=?, FLOAT_VALUE=?, DATE_VALUE=?, FACTOR_ID=? where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '4017' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(73) | binding null to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '6' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '22' to parameter: 6
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | update ccsphs.r_factor_value set TREATMENT_ID=?, FACTORSTRINGID=?, FLOAT_VALUE=?, DATE_VALUE=?, FACTOR_ID=? where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '12' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(73) | binding null to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '9' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '20' to parameter: 6
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | update ccsphs.r_factor_value set TREATMENT_ID=?, FACTORSTRINGID=?, FLOAT_VALUE=?, DATE_VALUE=?, FACTOR_ID=? where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '4005' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(73) | binding null to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '6' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '23' to parameter: 6
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | update ccsphs.r_factor_value set TREATMENT_ID=?, FACTORSTRINGID=?, FLOAT_VALUE=?, DATE_VALUE=?, FACTOR_ID=? where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '1' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(73) | binding null to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '1' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '19' to parameter: 6
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | update ccsphs.r_factor_value set TREATMENT_ID=?, FACTORSTRINGID=?, FLOAT_VALUE=?, DATE_VALUE=?, FACTOR_ID=? where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '2015' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(80) | binding '22.0' to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '5' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '21' to parameter: 6
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | update ccsphs.r_factor_value set TREATMENT_ID=?, FACTORSTRINGID=?, FLOAT_VALUE=?, DATE_VALUE=?, FACTOR_ID=? where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '1' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '5005' to parameter: 2
[CCS_R1] DEBUG [http-8080-Processor23] FloatType.nullSafeSet(73) | binding null to parameter: 3
[CCS_R1] DEBUG [http-8080-Processor23] IntegerType.nullSafeSet(80) | binding '4' to parameter: 5
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '24' to parameter: 6
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | delete from ccsphs.r_factor_value where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '18' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | delete from ccsphs.r_factor_value where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '17' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | delete from ccsphs.r_factor_value where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '22' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | delete from ccsphs.r_factor_value where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '20' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | delete from ccsphs.r_factor_value where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '23' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | delete from ccsphs.r_factor_value where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '19' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | delete from ccsphs.r_factor_value where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '21' to parameter: 1
[CCS_R1] DEBUG [http-8080-Processor23] SQL.log(393) | delete from ccsphs.r_factor_value where FACTOR_VALUE_ID=?
[CCS_R1] DEBUG [http-8080-Processor23] LongType.nullSafeSet(80) | binding '24' to parameter: 1