The GenericJDBCException is correct and indeed, I shouldn't be able to delete the object - it has references to children objects.
It is all of the successive attempts that make me think I can do something to CLEAN it out of memory. Successive attempts (which should also fail) are failing for a different exception ... NonUniqueNonUniqueObjectException. That, is the exception I'm trying to counter. That exception implies that the object I am trying to delete - is already "attached" to my hibernate session. That confuses me since, the successive delete requests are on subsequent posts which explicitly grab a new session. If I shutdown or navigate away from that page - and then visit it again, the first delete attempt results in GenericJDBCException ... which I expect. So, naively, this implies to me that maybe my framework is saving or 'caching' that object and reusing it on subsequent or immediate requests - whereas, when I navigate away, it is clearing itself and re-retrieving the object. This notion is somewhat reinforced as my drop down changes. The first attempt always prompts me with the "Choose One" option as well as the thing I'm trying to delete. Subsequent requests no longer include the "Choose One" option. IE: Wicket knows about and is holding onto the literal object I tried to delete (the model). Maybe I can set it (the model) to null or something to explicitly make that Change One appear again ... Thanks for the suggestion - I will try to mimic this in a test - but again, its not the DELETE I'm after, it is the odd exception that only shows up after subsequent DELETE attempts that I'm trying to understand better. -Luther But, the first attempt throws GenericJDBCException On Thu, Apr 2, 2009 at 8:32 AM, James Carman <[email protected]>wrote: > Have you tried what you're trying to do in a test case? I mean, > outside of Wicket? > > On Wed, Apr 1, 2009 at 10:19 PM, Luther Baker <[email protected]> > wrote: > > I am trying to delete an object in my form's Submit handler. > > > > In one case, the object has references to other objects and so it > correctly > > complains throws a (GenericJDBCException). When the view refreshes, the > > "Choose One" method is gone and the previously selected object is > selected > > again. If I submit the form it throws a different Hibernate error > > (NonUniqueObjectException) which all subsequent requests throw. If I > > navigate away from the page and back, the first exception to be thrown on > > deletion submit is again, GenericJDBCException - afterwhich subsequent > > requests throw NonUniqueObjectException. > > > > Per the OSIV pattern, I am creating a new Session and creating a high > level > > transaction in an outer JEE filter. > > > > I think this is all correct behavior but I'm wondering why the > > NonUniqueObjectException on all subsequent delete requests from the same > > page. The form is indeed tied directly to an instance of the object I am > > deleting. I am guessing that it is, as it indicates, trying to > continually > > delete an object that already exists in Hibernate's memory. > > > > Is there a way to correctly/formally "remove" the object from Hibernate's > > immediate memory? I think that is more than simply "disconnecting" it > since, > > each request by definition creates a new Session object to which, this > > particular Hibernate entity object isn't attached to. > > > > Thanks in advance. I'm a noobie to both so I apologize if this is really > a > > Hibernate question. > > > > -Luther > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
