Sorry I read too fast. Indeed if you are working from the representation in memory and not considering what happened in the backend, I don’t think it should happen or as you say something is fishy (like multi-thread abuse).
On 30 Sep 2014, at 09:10, Gunnar Morling <gun...@hibernate.org> wrote: > Thanks for coming back on this :) > > 2014-09-29 18:16 GMT+02:00 Emmanuel Bernard <emman...@hibernate.org>: > I think that can happen due to the weak transactional guarantees the > underlying backend provides. > Why do you ask? (that is if you remember as this email is quite old - > nothing like being stuck on a place for 12 hours to catch up ;) ). > > I'm not entirely sure anymore why I asked :) Maybe I considered to guard > against it using an assertion. > > Does it really depend on the capabilities of the store, though? Between > loading an Association and removing a RowKey from it, all is in our control > (and all in one thread). So if we invoke Association#remove() for a RowKey > which isn't present in the loaded Association object, it still seems fishy to > me. > > Note that's different from trying to remove an association row in the store > actually, there it may be gone already of course. > > On Wed 2014-08-27 22:40, Gunnar Morling wrote: > > Hi Emmanuel, > > > > Is there any legitimate case where Association#remove(RowKey) is invoked > > for a key which is not present in that specific association instance? Or > > would this indicate some programming error? > > > > Thanks, > > > > --Gunnar > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
