On Tue, Feb 8, 2011 at 7:11 AM, Daryl Stultz <[email protected]>wrote:
> On Mon, Feb 7, 2011 at 4:28 PM, Michael Dick <[email protected] > >wrote: > > > On Mon, Feb 7, 2011 at 1:41 PM, Daryl Stultz <[email protected] > > >wrote: > > > > > Yes, a query works, but em.find(MyCase.class, 123) will return the > > deleted > > > object from L1 if I'm not mistaken. I pulled the call to clear() as it > > > should be unusual to call find after deleting. I can't seem to uncover > > any > > > other side effects of the deleted object hanging around in L1. > > > > > > > That matches what I've seen. Is the find issue a blocker for you ? > > > > > No, I actually thought I would be preventing more heinous problems by > getting the deleted object out of L1. I thought that if the object was > modified prior to the JDBC delete, then another object was modified and > "saved", the save transaction would cause the deleted but dirty object > still > in L1 to be saved as well (assuming it is still managed), but I can't > demonstrate this in a unit test. > Haven't tried that scenario myself, and I'd be interested to hear what you find out if you have time to try it. The main impact I foresee is that the other entities could have a reference to a deleted row. Resulting in a constraint violation at runtime. Then again, you're running that risk so long as you have the legacy cron job that deletes rows unless your code gets a callback. -mike
