cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maik Musall <>
Subject Re: Read-only contexts?
Date Fri, 05 May 2017 11:06:56 GMT
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.


> Am 05.05.2017 um 12:29 schrieb Alexander <>:
> Hi,
> I searched for a while, but wasn’t able to find a solution to make an ObjectContext
> 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

View raw message