Two options that immediately come to my mind are: 1) Use separate DataContext instances. You could have one DataContext per window (or even more if it made sense). Creating a DataContext isn't a very CPU-intensive activity, so you won't incur a large cost making many of them. Of course, you can throw away contexts you don't want, too.
2) Use a nested DataContext. In your first window where you are checking for input errors, do that work in a nested DataContext. If you encounter errors and want to abandon it, again just throw away the nested context without committing changes to the parent. You could still unregister, but the above two options might be easier to implement. /dev/mrg On 7/31/07, Jan Lendholt <[EMAIL PROTECTED]> wrote: > Hey Folks, > > another question: > > I created an object via context.newObject(Service.class); > > Before I do a context.commitChanges() I check if there are any input errors > in the input fields that should be set to the object. If we encounter an > exception, we abort the creation / editing of the current object. > > Now, in the meantime, I take another window to create another object, like > context.newObject(Person.class) and call the context.commitChanges(). > > Now, the old object, at which the check of the data failed, ist committed as > well. > > Is there any method that prevents the commit of an object? > I just found context.unregisterObjects... is this the only possibility to > prevent a commit? > > Background: > > We have a swing-app using the objects and passing them in constructor calls. > If we encounter any problems upon editing this passed object and commit > changes on another object, all party changed things will be committed as > well, which is unliked by us. > > I hope I could explain clearly. > > Bye, Jan > > _________________________________________________________________ > Haben Spinnen Ohren? Finden Sie es heraus – mit dem MSN Suche Superquiz via > http://www.msn-superquiz.de Jetzt mitmachen und gewinnen! > >
