Hibernate version:
Validator 3.0.0GA
Annotations 3.3.0.GA
Core 3.2.2GA


I was using Annotations 3.2.0GA and the associated Core for several months. I swapped out the jars for the new versions, and found this error in my testing:

org.hibernate.validator.InvalidStateException: validation failed for: com.viz.web.model.campaign.Route
at org.hibernate.validator.event.ValidateEventListener.validate(ValidateEventListener.java:148)
at org.hibernate.validator.event.ValidateEventListener.onPreUpdate(ValidateEventListener.java:177)
at org.hibernate.action.EntityUpdateAction.preUpdate(EntityUpdateAction.java:217)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:65)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140)
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)



The log file also shows:

ReadWriteCache.handleLockExpiry(214) | An item was expired by the cache while it was locked (increase your cache timeout): com.viz.web.model.campaign.Route#93512


I checked the ehcache.xml file and had the settings:

<cache name="com.viz.web.model.campaign.Route"
maxElementsInMemory="2000"
eternal="false"
overflowToDisk="true"
timeToLiveSeconds="3600"
/>


Everything looks to be in order. I am wondering if there is a bug in the new version, or if it requires a code change in any types of logic?

Well, is Route a valid object?

What does the InvalidStateException contains?

Sorry for not giving enough info. I was mainly concerned with the cache warning that I had either not noticed or not received in the past.

What I have is a web form with a master/detail setup. I am calling getInvalidValues on the ClassValidator from my controller. It passes validation here and calls hibernate to saveOrUpdate the master object (With Cascade ALL and DELETE_ORPHAN).

In the older version this worked. In the newest version I get the validation error, but only during the save.

What I found is that the master object has a Set of the Routes. It does not have the @Valid annotation. This I think is the source of the differing behavior.

The Route object had @Future on a begin and enddate, which works great for inserting new rows, but terribly for editing existing rows. This was the source of the error being reported. I had to remove the @Future annotations here to fix the problem.

I found that there is a call to save the Route object directly in one case. So, it is my code that was the problem. The only difference is that it appears that Annotations 3.2.0GA was not checking my @Future tags on this detail object, while 3.3.0GA/Validator 3.0 does.

Thanks.

I don't fully understand why this was not triggered before. Here is the reason why calling Validator might "behave differently" than an Hibernate call:

If a Route is considered dirty, it will be validated so if @Valid is not used and parent is valid, the Route object will still raise an issue by cascade.

(on a side note components ie embedded objects are also validated by cascade even if @Valid is not here)

Did you change the cascade setting?

I did not change the cascade setting.

That is interesting and goes against some assumptions I had made. I had assumed that the ClassValidator would function identically when called from a controller or via a Hibernate call. Based on this, I had always considered the Dao level validations to be a catch all incase an app had a bug, and that a well tested app would never issue validation errors during Dao layer calls.

In my case, Route was definately dirty. I was loading the master object and the set of Routes. Users were then editing fields on both the master and some of the Routes.

I am trying to think of a case when an app would not want @Valid on a field using cascade. Perhaps an enhancement request is needed to provide warnings in the log at startup for these cases.

While I am thinking of it, the ability to make a distinction between a save or an update in certain validations would be very useful. @Future is unusable in most cases where users may Update rows.

Easier to say than to implement. the problem is that some people will use XML to describe their persistence metadata (I know, I know).
Anyway the catch up seemed to work :-)

On a general basis, Hibernate and its persistence context will usually know much more on your object graphs (and their state) than your application.

I personally have never been keen on @Past and @Future, they are more contextual validation than static domain constraints.

I think the simple fix for this case is to add something to the documentation saying that if you are using Annotations and Validator, be sure to always have @Valid when using cascade. Any further insight you could give about how the hibernate call to Validator could differ from a manual call to the validator would be helpful to users.

I understand your feeling about @Past and @Future. @Past is fine because we are never moving back in time. Hibernate knows that a field has changed when doing a dirty check. It does not issue update statements that include all fields.

When doing an insert, all fields are differrent from the database, and must all be validated. When doing an update, there is a distinction between the fields that are being changed and those remaining unchanged.

With @Future, I would think that for a given date, if the date is to remain unchanged, it would not need to pass this validation. The allowable values would be:

1. The prior (in the past) date.
2. An updated date that must pass validation.

I know @Future is the only good example I have, but the other validations could fall under the same thought process.

Suppose I have a good valid row in the db. Some other app that connects to the db messes up a field. They change a number value to be out of the min/max set in hibernate validator. Then our app loads this data. The end user gets an error message without even trying to modify anything.

Technically that is how it should work, but often the end user of our app cannot be expected to fix the data problem caused by someone else. In some apps, the designer would prefer the validation to be skipped if the end user did not modify that field.

I know this is all debatable, but if it was easy enough to implement someday, I see a use for being able to say something like @Future(ignoreNonupdatedField=true)

By default Hibernate update all columns when an update is triggered.
WRT your third party app update, that's exactly why data constraints should be expressed at the DB level :-)

That's true, I definately use the DDL constraints, but for @Future there are no such constraints. Nor are there DDL constraints for @Email or @CreditCardNumber.

As a follow-up, I would like to what what if any are the subsequent effects of this:
An item was expired by the cache while it was locked (increase your cache timeout)

Is it something that can cause serious problems? - I mean something more than a performance issue.

Thanks in advance.