On 04/20/2012 02:31 PM, Linda DeMichiel wrote:
>
>
> On 4/20/2012 8:39 AM, Scott Marlow wrote:
>> I'm exactly sure how the word "immediately" applies in section 3.6.1,
>> where we describe when the validation will happen
>> after lifecycle events.
>>
>> If the application calls EntityManager.persist() and then calls
>> EntityManager.flush(). Then sometime later the jta
>> transaction commits. What if the pre-persist is triggered as part of
>> em.persist() but the validation happens during
>> em.flush or commit (before completion)?
>>
>
> PrePersist validation is supposed to occur at the same time as the
> PrePersist callback methods after all
> of the callbacks methods have been invoked--i.e., before persist().
> PostPersist validation may happen at
> the end of the transaction, but I don't understand your question about
> PrePersist validation happening then.
>
I'm trying to understand if its up to persistence providers to define
what "immediately" means to them or if a stricter definition should be
used. My read of the current wording, is that it is not 100% clear what
the intention of the use of "immediately" is.
In the above example that I gave, if the validation is performed after
pre-persist and before TX completion, then the validation is performed
"immediately enough" to function correctly (I think).
>> How does the term "immediately" apply in this context and why is that
>> a requirement?
>>
>
> Well, for one thing, assuming the application has invoked persist(), it
> gives it a deterministic point
> at which to catch any validation errors.
>
>> Current text from 2.1:
>> "
>> 3.6.1 Automatic Validation Upon Lifecycle Events
>>
>> This specification supports the use of bean validation for the
>> automatic validation of entities upon the pre-persist,
>> pre-update, and pre-remove lifecycle validation events. These
>> lifecycle validation events occur immediately after the
>> point at which all the PrePersist, PreUpdate, and PreRemove lifecycle
>> callback method invocations respectively have been
>> completed, or immediately after the point at which such lifecycle
>> callback methods would have been completed (in the
>> event that such callback methods are not present).
>>
>> In the case where an entity is persisted and subsequently modified in
>> a single transaction or when an entity is modified
>> and subsequently removed in a single transaction, it is implementation
>> dependent as to whether the pre-update validation
>> event occurs. Portable applications should not rely on this behavior.
>> "
>>
>> Scott
>>