Hi Alexander, I suppose you could create your own ObjectContext subclass which does it, by overriding commitChanges() and related methods. I always recommend using custom subclasses of ObjectContext in any case, with a factory providing them, so you could always change the behaviour by extending the factory to produce other subclasses.
Maik > Am 05.05.2017 um 12:29 schrieb Alexander <[email protected]>: > > Hi, > > I searched for a while, but wasnât able to find a solution to make an > ObjectContext âread-onlyâ. > Maybe I'm missing something. > > The point is: > As suggested many times, there are situations where it makes sense to have a > shared read-only ObjectContext and other ObjectContexts to commit changes. > I can certainly handle two and more ObjectContexts, but I need to lock out > other users / applications which can somehow gain access to persistent > objects instantiated through the assumed read-only shared context, since any > application that has access to such objects (maybe obtained from a service > class that is expected to return read-only objects) could simply call > object.getObjectContext().commitChanges(). By the way, this would also commit > unwanted temporary changes that happen elsewhere in the main application or > in the service class. > > Is there a method like CONTEXT.makeReadOnly() to make sure that any objects > that resides in this specific ObjectContext cannot be changed? > Even better, is there a way to let persistent objects, that are bound to a > read-only context, throw an exception? > > Should this be possible, there is only one question left: would it still be > possible to transfer objects retrieved through a read-only ObjectContext to > a read-write ObjectContext, by calling localObject(readWriteContext)? > > Any help would be greatly appreciated. > Alexander >
