Hi Marcel,

My example refers to different use-cases operating on the *same*
(identical) set of objects, setting and unsetting the read-only bit willy
nilly to suit their purposes, and conflicting with each other.  There's
only one bit per object.

As far as partitioning within ManagedObjects, I assure it's something
you're *definitely* going to need, but you'll still need to ensure all
users of beWritableObject, et al, in any one image, are coordinated.

 - Chris

On Fri, Apr 24, 2020 at 5:10 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> >  But this means the DB is now occupying the use of the readOnly bit,
> not available for other applications or use-cases.
>
> Hmmm... ManagedObjects could be partitioned among multiple applications.
> For example, a game loading some save state could come across some
> read-only objects and then choses how to manage those. Another application
> could do this as well, not interfering with the first one. Both might be
> considered "small DB managers" so to say.
>
> Of course, that check "myDomainObject isReadOnlyObject" would become
> standard procedure for such DBs, wouldn't it?
>
> Best,
> Marcel
>
> Am 24.04.2020 05:26:56 schrieb Chris Muller <ma.chris.m at gmail.com>:
>
>> So if the exception is unhandled, then before it raises an UnhandledError
>>> it checks an identity dictionary, which maps object to message, and if the
>>> read-only object that was the cause of the error is in the dictionary,
>>> instead the exception performs the message with the object as an argument.
>>> So a database layer can add the objects it is managing to the map in
>>> ModificationForbidden, and mark them as read-only.  Then any and all
>>> attempts at modifying these objects will cause the database man ager to be
>>> notified.
>>>
>>  So very simply we can have a pluggable solution that allows different
>>> clients to map the exception into different responses as desired.
>>>
>>
>> But an object in your db table could easily be an Array literal held by a
>> CompiledMethod, not expected to change, but persistent by reference
>> nonetheless.  So if the application did then modify it accidentally,
>> instead of Forbidden protection, your DB manager would happily modify it.
>> It's this separation of use-cases is all what the question was about I
>> think, not a big deal, we've lived with unprotected CM literals for this
>> long already, and I've never needed WriteBarrier for anything other than a
>> DB.
>>
>>
>> Since objects get added to the collection intentionally the array literal
>> would not be added and hence the manager would not modify it.
>>
>
> How would the manager know not to add it?  It can't be by checking
> #isReadOnlyObject, since that presents the same paradox -- requiring the
> manager to know the business of whatever other use-case has it set.  If it
> assumed it was for CM-literal protection, it wouldn't add it, but what if
> it was just some debugging or something?
>
>
>> Your example is a straw man.
>>
>
>>
>> However, I still don't see the path for how to use this in a complex
>> multi-db Magma application with oblivious objects (e.g., Morphs).  It's not
>> something any of the GemStone clients I consulted at as developer or DBA
>> ever had to contend with either, but perhaps not something you're
>> targeting.  Squeak is a different animal...  I will stay tuned here and
>> watch for the answers as they unfold...
>>
>>
>> The objects that get added to the wrote barrier management collection get
>> added by managers that want to manage specific objects, not arbitrary
>> objects. Can you see that a DB manager would add objects it has
>> materialized from the DB that it wanted to transparently write-back in
>> modification, and no others?
>>
>
> Yes, absolutely.  The manager will get every ModificationForbidden signal
> under its code whether its meant for the DB or not.  Existence in a global
> table means handle it, otherwise pass it up the stack.  But this means the
> DB is now occupying the use of the readOnly bit, not available for other
> applications or use-cases.
>
> I hope this critique isn't taken to mean I don't think this isn't a good
> feature for the VM and image.  I do.  Everything is a balance of features
> and limitations.  I'm still trying to determine whether Magma can benefit
> from this, and I have to get deeply critical to find the right decision.  I
> will be following this feature closely, thanks for your patience with my
> questions.
>
>  - Chris
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200424/32848a81/attachment.html>