Details
-
Type:
Sub Task
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.1-JPA
-
Component/s: JPA, Unit Testing
-
Labels:None
-
Similar issues:
KULRICE-3859Make rice unit tests work with JPA KULRICE-3861Make KNS unit tests work with JPA KULRICE-3862Make KEW unit tests work with JPA KULRICE-3863Make KIM unit tests work with JPA KULRICE-3864Make KEN unit tests work with JPA KULRICE-3896KNS Unit Test BOs need to be JPA annotated KULRICE-3853JPA - Proof of concept with sequence / identity/ prePersist KULRICE-13860 Implement a more extensive suite of integration and unit tests against the KSB module KULRICE-3813JPA - JPA 2.0 testing KULRICE-6119Document simple KSB-only setup -
Rice Module:KSB
Description
Make KSB unit tests work with our JPA implementation
Activity
Still working on StoreAndForwardTest. I put a sequence diagram together to help reason about what I'm seeing and attached it here: https://test.kuali.org/confluence/display/KULRICE/Store+and+Forward+implementation
It appears to be a timing issue: after the service method is invoked on the destination service from the KSB-Pool thread, it goes to delete the PersistedMessage. At about the same time, the main thread's MessageServiceInvoker is trying to delete it's copy of the PersistedMessage. Almost all of the time this is resulting in an OptimisticLockException when I'm testing. It didn't happen with OJB, but I'm guessing it was just due to fortunate timing – I may be wrong though.
So here are a few questions:
1. Why is the PersistedMessage being persisted at all? It doesn't seem to ever be retrieved during its lifetime.
2. Any idea why the ForwardedCallHandler makes a copy of the PersistedMessage and then does nothing with it?
3. I have one hypothesis, which is that the ForwardedCallHandler is actually supposed to pass on the copy it made of the PersistedMessage, which would then be saved / deleted in a separate row and no OptimisticLockException would occur. Does that sound plausible?
In the truly asynchronous case (without the SynchronousServiceCallProxy involved), it seems like the persisted message would be stored and deleted rather quickly, then stored and deleted again. I'm not sure what the point is.
Determined that the problems with getting the MessageQueueDAOJpaImpl working well enough for the unit tests to pass stemmed from a bug in the ForwardedCallHandlerImpl. See KULRICE-3887
I had a sticks and bubblegum fix for MEssageQueueDAOJpaImpl at the f2f that had all of the tests passing, but I'm having a heck of a time making this work without resorting to using JPQL for deletes. Right now with my local code there is a timing issue where two removes of the same entity are happening at the same time in different threads, and an OptimisticLockException almost always occurs that breaks the test. The only remedy I've been able to come up with is equally horrible, putting the remove in a synchronized block which locks on a VM-global object. Lots of head banging going on here.