|
Boost : |
From: Preston A. Elder (prez_at_[hidden])
Date: 2006-04-10 12:02:54
I also have another follow-up question, regarding the same thing.
I'm pretty sure this is possible by reading the docs, but its not a
documented feature (I'm not surprised, really).
How do I do the equivalent of a la.reset_object_address(v, u) for an
object that has NOT been serialized with that archiver?
The situation is this, I will obviously have to have an iarchive and
oarchive class - to accomodate failing over between instances of my
application (remember, my [io]archive instances will remain active
throughout the application). Therefore, when I send something to an
oarchive (ie. the primary replicating 'out'), I also need to add that
reference to the pointer tree maintained by iarchive. Similarly, when
I receive the item via. an iarchive (ie. the secondary replicating 'in')
I need to add that reference to the pointer tree maintained by oarchive.
If I could make an iarchive and oarchive use a common pointer reference
tree, that would be ideal (I'm not very worried about thread safety
since only one would use it at a time), however if not, I need to keep
the complementing object references up to date in case of fail over.
Why? Because if my primary goes down, and I fail to my secondary, it
now becomes the 'master' and starts replicating out itself. Because of
this, it needs to be able to pick up where the old primary left off
(both in case of any tertiary instance listening, and because if the
primary comes back up it will want to be replicated to again, becoming
the secondary).
The more I think about this, the more it seems I'm trying to hammer a
round peg into a square hole - especially considering I know that each
tracked object is assigned an ID, and that ID would have to be
maintained between the iarchive and oarchive instances to be able to
change from a consumer into a producer like that and have third party
consumers not notice the difference.
Any ideas, etc. would be welcome. Also, might I make a request to the
maintainer of serialization to hopefully turn boost::serialization into
something that can be more suitable for replication purposes in a
future release of boost? The interface of boost::serialization is
fantastic, but the implementation I think needs a few more knobs and
switches to enable a wider variety of purpose.
-- PreZ :) Death is life's way of telling you you've been fired. -- R. Geis
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk