Trying to understand forwarding proxies

[Chris Muller]

Hi,

>> One repository is served by one or more servers at a time.
>
> Does this mean that magma handles file locking of files and
> transaction/timestamping data inside the files to be safe to have any number
> of images accesing it?

No, only one Squeak process at a time can access one physical copy of
a repository at a time.  In fact, a temporary file is created as a
crude-but-effective check just to prevent accidentally opening a
second process on the same files.

When I said "one or more" I was referring to an HA configuration.  One
_logical_ repository, of which there are multiple physical copies,
each "served" by one squeakvm process concurrently.

HA configurations can help scaling an applications read performance,
but not its write performance.  For that, FP's can help.

> Ok. Seems like a nice feature that opens a whole new bunch of possible use
> cases. I can imagine that can be very useful if there is a balanced domain
> partitioning in place.

As an example, I have a Magma app for personal finances.  The users
financial information is kept in one repository.  But since the domain
includes references to various FinancialSecurity objects (as in stocks
or mutual-funds) and their price history for calculating portfolio
values, it really makes sense to partition that part of the domain out
to its own repository (called "FinancialWorld" for discussion).  That
way, there is only one copy of the repository which can be referenced
from multiple external repositories / applications.

> I assume that copying a tree from one repository to
> another is just a detach/attach operation, right? Forwarding proxies can
> close some gaps I think.

Maybe not _copying_ a tree, but _referencing_ a tree in another
repository is a commit of just one object-pointer to a FP instance.

> I agree. I didn't mix HA with scaling. Btw. is the master server
> automatically taken over by another one if the master goes down?

It is automatic, but a secondary will not assume the primary role
until it is sent a request that only the primary can carry out, like
#commit.

So, if the primary goes down only briefly, and only reads came in
during that time, not commits, then when the primary comes back up it
will still be the primary.

If a commit does come in, the secondary must assume primary role.  It
does so automatically.  Then, if the original primary is restarted, it
will join the node as a secondary.  The node is running fine, but the
admin can force a primary-secondary swap without disrupting service if
the original configuration is desired.

>> A FP only points to one object in one repository.  The FP, itself, is
>> a persistent object residing in one repository.  In general, the only
>> requirement for the client app to do this is, whereever it SETS the
>> object that you want remotely-linked, just send
>> #asMagmaForwardingProxy to it.
>>
>> When that is committed, the object it refers to MUST be already
>> persistent in its own repository so an appropriate location of that
> >remote object can be determined and persisted with the FP.
>
> I assume you mean the referred object needs to have been persisted before to
> create an oid that is used in the proxy?

"referred object" = "object it refers to"

So, with the financial program, the FinancialSecurity instance, must
exist in the FinancialWorld repository before the ForwardingProxy
instance, which refers to it, is persisted in the users
personal-finance repository.

> Is that a normal MagmaSession like I create in my app?

Yes.

> If so, can I access
> automatically created sessions?

You can ask any object for its #magmaSession.

I like to open a session to the shared repository (FinancialWorld)
when I bootstrap my app for the first time.

> Let me bother you with some scenarios. Just to be sure I understood you
> correct.
> Let's take 10 machines (EC2) that have all attached a shared storage all of
> them could access the same repository in a safe way, right?

They could access the same _logical_ repository, of which there would
need to be 10 physical copies.

> If this is
> possible then locking will prevent scaling when a specific number of
> accessing processes is reached. I could then partition the user data into
> multiple repositories and still have the ability to access them from
> multiple machines or to switch responsibility of a repository from one host
> to another? Furthermore it would be possible to have a central server that
> keeps information (that is not easy to partition) and that references/is
> referenced via forwarding proxies from other servers? And mutating proxies
> might help to lower forwarding requests by materializing the object in
> another repository. And if it is needed I could even store images that
> recover automatically when restarted again?
> Well, that sounds to good to be true;

(These questions are based on that wrong assumption about the file
locking.  Magma doesn't do that.)

FP's are simple.  They're just a soft-link from one logical repository
to another.

 - Chris



> thanks,
> Norbert
>
>
> _______________________________________________
> Magma mailing list
> Magma at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/magma
>
>