Sequence numbering problem... solved.

Chris Muller asqueaker at gmail.com
Sat Nov 22 16:30:19 UTC 2008


Hi sig,

> I think its quite possible, since you anyways need to serialize
> requests to server - if you discover a proxy, you can reify it , or
> maybe just serialize its ID without need in reifying it on client
> side, which is much faster.

Just to clarify, there are two sets of serializers on each of the
client and server.  One serializer converts buffers in the repository
to and from buffers and objects, the other converts *requests and
responses* to and from buffers and objects.  Never the two should
cross, which reminds me, Göran, that, although not explicitly
necessary, it would be good form to *copy* the UUID you pass in the
request, just so it is its own object.  This would, in fact, have the
beneficial side-effect of reifying it and avoiding the problem you had
in the first place.

So requests and responses are fully serialized object trees, never
expected to have any proxies whatsoever.  If there is a proxy in a
request I consider it a bug.  This is also the reason you cannot
simply reference the proxy by oid in the referencing buffer, the
TcpRequestServer is generic, it does not know anything about Magma,
and will not go looking into any repository for what object it is.

 - Chris


On Fri, Nov 21, 2008 at 8:00 PM, Igor Stasenko <siguctua at gmail.com> wrote:
> 2008/11/22 Chris Muller <asqueaker at gmail.com>:
>> Thanks for the report Göran.  Good debugging, another option would be
>> to employ a ReadStrategy to ensure the UUID is dereferenced in the
>> original server call.
>>
>> This never came up because serverPerform: was added solely for this
>> purpose (sequence # generators), and a proxy would never be part of
>> any of the other requests.  Still, you've piqued my curiousity whether
>> Magma could make this invisible for you.
>>
>
> I think its quite possible, since you anyways need to serialize
> requests to server - if you discover a proxy, you can reify it , or
> maybe just serialize its ID without need in reifying it on client
> side, which is much faster.
>
>> Regards,
>>  Chris
>>
>> On Tue, Nov 18, 2008 at 4:26 PM, Göran Krampe <goran at krampe.se> wrote:
>>> Hi!
>>>
>>> As Chris knows we need sequence numbers in Gjallar. Chris implemented
>>> #serverPerform:withArguments: but I admit being slightly stumped with it.
>>>
>>> I think the idea is that you add methods to MagmaRepositoryController like
>>> for example:
>>>
>>> q2CounterInitialize: anId
>>>        | sess counter |
>>>        counter := 0.
>>>        sess := self session.
>>>        sess cacheAt: anId put: counter.
>>>        ^sess commit: [ sess root environment at: anId put: counter ]
>>>
>>> q2CounterNext: anId
>>>        | sess |
>>>        sess := self session.
>>>        ^sess commit: [ sess root environment at: anId put: (sess root
>>> environment at: anId) + 1]
>>>
>>> q2CounterValue: anId
>>>        | sess |
>>>        sess := self session.
>>>        ^sess commit: [ sess root environment at: anId ]
>>>
>>>
>>> ...and then we call them, right? Soo... today I ended up getting errors
>>> about serialization:
>>>
>>> "MaMalformedRequestError: No createProxyBlock specified.  See
>>> MaObjectSerializer>>toCreateProxies:"
>>>
>>> Aha... I think I realized this now - the id above is a UUID but we are
>>> sending a MaMutatingProxy instead. So I added just a little call like "{id
>>> yourself}" to make sure it gets faulted - and then it seems to work.
>>>
>>> regards, Göran
>>>
>>> _______________________________________________
>>> Magma mailing list
>>> Magma at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/mailman/listinfo/magma
>>>
>>
>> _______________________________________________
>> Magma mailing list
>> Magma at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/magma
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Magma mailing list
> Magma at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/magma
>
>


More information about the Magma mailing list