hi,

i've got a problem with hibernate version 2.1.6 and 2.1.5. In case of setting "dynamic-update" to "true" the update-statement seems to be not correct.

With hibernate 2.1.4 my little test runs perfectly. I only change the libs ... no source.

Could someone please give me a hint?

thx!
Carsten

Hibernate version:
2.1.6

Hibernate-Mapping-Excerpt
<class
name="hibernate.test.Test"
table="TEST"
dynamic-update="true"
optimistic-lock="all"
>
<cache usage="read-write"/>

<id
name="atnr"
column="ATNR"
type="short"
unsaved-value="0">
<generator class="sequence">
<param name="sequence">atnr_sequence</param>
</generator>
</id>

....
</class>

Full stack trace of any exception that occurs:
net.sf.hibernate.JDBCException: could not update: [hibernate.test.Recht#110]
at net.sf.hibernate.persister.EntityPersister.update(EntityPersister.java:707)
at net.sf.hibernate.persister.EntityPersister.update(EntityPersister.java:642)
at net.sf.hibernate.impl.ScheduledUpdate.execute(ScheduledUpdate.java:52)
at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2418)
at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2372)
at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2240)
at hibernate.persistenz.DBAccess.run(DBAccess.java:77)
Caused by: java.sql.SQLException: The number of parameter values set or registered does not match the number of parameters.
at com.ibm.as400.access.JDError.throwSQLException(JDError.java:325)
at com.ibm.as400.access.AS400JDBCPreparedStatement.commonExecuteBefore(AS400JDBCPreparedStatement.java:473)
at com.ibm.as400.access.AS400JDBCStatement.commonExecute(AS400JDBCStatement.java:599)
at com.ibm.as400.access.AS400JDBCPreparedStatement.executeUpdate(AS400JDBCPreparedStatement.java:949)
at net.sf.hibernate.impl.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:22)
at net.sf.hibernate.persister.EntityPersister.update(EntityPersister.java:684)
... 6 more

Name and version of the database you are using:
IBM DB2 AS400

The generated SQL (show_sql=true):
update TEST set ATBEZ=? where ATNR=? and ATBEZ=? and ATBEF=? and ATKZ=?

Values only for Parameter 1 and 2 are set. All other Parameters are ignored.

Debug level Hibernate log excerpt:

11610 [Thread-0] DEBUG net.sf.hibernate.impl.BatcherImpl - about to open: 0 open PreparedStatements, 0 open ResultSets
11610 [Thread-0] DEBUG net.sf.hibernate.SQL - update TEST set ATBEZ=? where ATNR=? and ATBEZ=? and ATBEF=? and ATKZ=?
11610 [Thread-0] DEBUG net.sf.hibernate.impl.BatcherImpl - preparing statement
11641 [Thread-0] DEBUG net.sf.hibernate.persister.EntityPersister - Dehydrating entity: [hibernate.test.Recht#110]
11641 [Thread-0] DEBUG net.sf.hibernate.type.StringType - binding 'TestTest' to parameter: 1
11641 [Thread-0] DEBUG net.sf.hibernate.type.ShortType - binding '110' to parameter: 2
11641 [Thread-0] DEBUG net.sf.hibernate.impl.BatcherImpl - done closing: 0 open PreparedStatements, 0 open ResultSets
11641 [Thread-0] DEBUG net.sf.hibernate.impl.BatcherImpl - closing statement
11641 [Thread-0] DEBUG net.sf.hibernate.util.JDBCExceptionReporter - SQL Exception

hi,

has nobody an idea what the problem might be? Or is it just the wrong place to ask this question?
I've tried it a lot of times (two Threads which acts concurrently and synchronized so i can reproduce this error every time) and i'm sure i've done everything right, because with Version 2.1.4 this exception doesn't occur ...
(some source - only changed the libs)

Or do you need more information?

I would be very glad if someone could give me a tip ...

Sure i can use version 2.1.4 (i'm doing that at the moment) ... but it's not really a solution ;)

thx!
carsten

P.S.: I've seen that i've some mistakes in the mapping-file ... better use cut & paste next time ... sorry ...but in "real live" the mapping file is correct! With version 2.1.4 everything works fine ...

please submit a runnable test case to JIRA, thanks

okay. thanx! i've added an issue in JIRA: Key is HB-1254

gtx
carsten

thanks gavin for your answer in JIRA.

I've found a thread (http://forum.hibernate.org/viewtopic.ph ... c&start=15) where you've said, that this feature is on your todo-list ... in combination with "select-before-update" ...

Anyone knows if it's implemented so far? My little example doesn't work (but perhaps i've got something wrong) ...

I still don't know why my little example (added in JIRA) works fine with version 2.1.4 and detached objects, but after reading the above mentioned thread i have a better understanding why it's not working.

gtx
carsten

Hi all,

I have hit this problem too, and tracked the problem to line 665 of net.sf.hibernate.persister.EntityPersister.java, there seems to be a bug with isVersion() check done in this line. Hibernate 2.1.6 has CVS version 1.46 of this file, but the CVS base has a 1.48 version of this same source code where this bug seems to be fixed (thanks to oneofthafew), maybe it will be added on the v.2.1.7 version roadmap. The fix mentions optimistic-lock=dirty being fixed, but it seems to apply to optimistic-lock=all too, as my tests have shown.

Regards,
Henrique Steckelberg

wow! thanks!
i've downloaded the current version from cvs and run my little test again.
With "optimistic-lock='all'" the first thread is able to write to the database now, the second still isn't but the exception has changed to:



(same effect by using "optimistic-lock='dirty'" or setting "select-before-update='true'".)

So something really has changed ...

The interessting point is, that all parameters are correctly bound to the prepared-statement now ... running the generated sql

(added the parameters from log) by hand works fine, too ...

Now it seems, that there's still a problem ... but setting the parameters works fine ...

regard,
carsten

i've made some further tests with the current cvs-version.

It seems to me, that the concurrency-handling doesn't work in this situation, because the "NonBatchingBatcher" tries to execute the sql-update and get's an "expectedRowCount=1" in Method "addToBatch" as input-parameter from "EntityPersister".
Because another thread had changed the data the update-statement won't change the database and the resulting rowCount is "0" ...
(i traced these values ... )
Then the above metioned exception is thrown because expectedRowCount != rowCount ...

gtx
carsten

sorry for tripple-post but i wasn't able to find the "edit"-button :)

I've found some differences between version 2.1.4 and cvs-version that (for me) are the 'problem' ...

Version 2.1.4. and update:
EntityPersister line 686 - the result of the update-statement gets checked by the AbstractEntityPersister's check-Method (line 499). The rows-parameter is "0" because the update wasn't possible and the "StaleObjectStateException" is thrown --> Concurrency

Version cvs and update:
The same sql-statement is interpretated as "batchable" (don't know exactly what this means) and the result is beeing checked by the (in my case) "NonBatchingBatcher" which throws a "row not found"-Exception instead of a "StaleObjectStateException" though it's the same situation.


Currently i think, if the Batcher would react the same way as the AbstractEntityPersister does, everything would be fine ... as a workaround i can interpretate the Hibernate-Exception ("row not found") as "StaleObjectException" ...

so my question: Why does the Batcher reacts different to the AbstractEntityPersister?

gtx
curio