Re: Failover for SO's with context

Question

Right, delivery of events is not guaranteed by Forte, even though
it is reasonable to rely on it in the case of two Forte servers on a LAN.
I would not go towards a solution for securing events delivery by
an acknowledgement mechanism (ack event or shared object notifier),
because of increased complexity and performance overhead.
On the other hand, a second simple security level can be provided by
enabling
your mirror/backup SO to be refreshed at will, by letting it get a
snapshot
of the current transient data to be mirrored, so you can :
- Start your partitions in any order (The mirror partition will first
task a
snapshot of the transient data, then will register for mirror events)
- Start and stop the mirror partition at will, without disrupting the
application
Then, if you do not trust events delivery, you can reinitialize your
mirror
periodically (say every 12 hours) to minimize the risks of losing
transient
data events.
Again, this solution is suited to low volumes of transient data.
I guess what Chad means by journaling is writing to a log file any
event (in a large sense) happening on data from its initial value. Then
if
you need to restore state, you re-play the events from the initial value.
This is a common solution in the banking area where you need to backup
values but also events on the values. I do not know how this can be
applied
to a generic mechanism with Forte, but it may be a good way to explore,
although probably more complex to implement with Forte than the
Backup SO/ Events pattern.
Hope this helps,
Vincent Figari
On Fri, 13 Feb 1998 10:39:03 -0600 Chad Stansbury
<[email protected]> writes:
Actually, since events (let alone distributed events) are not
'guaranteed delivery' in Forte, I would hesitate to use events
as a mechanism of mirroring your data - unless, of course, you
really don't require an industrial strength failover strategy.
This would also apply to asynchronous messaging (unless you
are careful to register for exception events (which again, aren't
guaranteed delivery) and have a mechanism to handle said
asynchronous exception events. I also know that Forte will retry
certain tasks when the service object it is sent to fails com-
pletely (like a NIL object exception), but don't know enough
about the internal workings of Forte to know under which conditions
this will occur.
I think that the most common method of a truly industrial-
strength, guaranteed-delivery mechanisms is via journaling...
which I know very little about, but is something that you should
be able to look up and study if that's what you require.
Again, if you don't care about the (admittedly small) chance
of an asynchronous call failing, then the suggestions that
Vincent has already made are good ones.
From: [email protected]
To: [email protected]
Cc: [email protected]
Sent: 2/13/98 9:13:17 AM
Subject: Re: Failover for SO's with context
Steven,
The pattern choice between external resource vs SO is dependent on the
type
of transient data you want to backup. Probably the external resource
is
better
suited to high volumes of data. We have implemented the 'Backup SO'
pattern because our transient data volumes are rather low (which I
guess
must
be the most common case for global, transient data).
Whatever the choice you do :
- Be sure to enforce encapsulation for updating the transient data, in
order to
guarantee that any modification to your transient data is duplicated
on
the backup
SO or the external resource
- About performances, the CPU cost is fairly low for your 'regular'
application if you
take care to :
* use asynchronous tasks to update the external resource
or
* use events to notify the backup SO
Now it is true that you will have a network overhead when using
events,
as your
backup SO shall be isolated in a remote partition on a remote
server.
That is one good argument to select the Backup SO pattern for low
volumes of
transient data.
If you choose the 'Backup SO' pattern, you will also have to be
careful
not sending
any distributed reference to your Backup SO but only clones.
Anyway, the backup SO pattern works fairly well for low volumes of
data,
but requires lots of testings and a good understanding of events and
communication
across partitions.
Hope this helps,
Vincent Figari
On Fri, 13 Feb 1998 09:24:57 +0100 Steven Arijs <[email protected]>
writes:
We're going to implement a failover scenario for our application.
Unfortunately, we also have to replicate the state of our failed
service
objects.
I've browsed the Forte site and found a TechNote concerning this
(TechNote 11074).
In this TechNote they talk about a service object that is responsible
for updating all backup service objects when needed.
It seems to me that when I implement that way, I will be creating a
lot
of overhead, i.e. I will be doing a lot of stuff several times.
What will be the effects on my performance ?
The way with the least performance loss would be to use an external
resource that is updated. But what if this external resource also
fails
Is there any one who has already implemented a failover scenario for a
service objects with state ?
Any help would be appreciated.
Steven Arijs
([email protected])
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

Answer 1

Right, delivery of events is not guaranteed by Forte, even though
it is reasonable to rely on it in the case of two Forte servers on a LAN.
I would not go towards a solution for securing events delivery by
an acknowledgement mechanism (ack event or shared object notifier),
because of increased complexity and performance overhead.
On the other hand, a second simple security level can be provided by
enabling
your mirror/backup SO to be refreshed at will, by letting it get a
snapshot
of the current transient data to be mirrored, so you can :
- Start your partitions in any order (The mirror partition will first
task a
snapshot of the transient data, then will register for mirror events)
- Start and stop the mirror partition at will, without disrupting the
application
Then, if you do not trust events delivery, you can reinitialize your
mirror
periodically (say every 12 hours) to minimize the risks of losing
transient
data events.
Again, this solution is suited to low volumes of transient data.
I guess what Chad means by journaling is writing to a log file any
event (in a large sense) happening on data from its initial value. Then
if
you need to restore state, you re-play the events from the initial value.
This is a common solution in the banking area where you need to backup
values but also events on the values. I do not know how this can be
applied
to a generic mechanism with Forte, but it may be a good way to explore,
although probably more complex to implement with Forte than the
Backup SO/ Events pattern.
Hope this helps,
Vincent Figari
On Fri, 13 Feb 1998 10:39:03 -0600 Chad Stansbury
<[email protected]> writes:
Actually, since events (let alone distributed events) are not
'guaranteed delivery' in Forte, I would hesitate to use events
as a mechanism of mirroring your data - unless, of course, you
really don't require an industrial strength failover strategy.
This would also apply to asynchronous messaging (unless you
are careful to register for exception events (which again, aren't
guaranteed delivery) and have a mechanism to handle said
asynchronous exception events. I also know that Forte will retry
certain tasks when the service object it is sent to fails com-
pletely (like a NIL object exception), but don't know enough
about the internal workings of Forte to know under which conditions
this will occur.
I think that the most common method of a truly industrial-
strength, guaranteed-delivery mechanisms is via journaling...
which I know very little about, but is something that you should
be able to look up and study if that's what you require.
Again, if you don't care about the (admittedly small) chance
of an asynchronous call failing, then the suggestions that
Vincent has already made are good ones.
From: [email protected]
To: [email protected]
Cc: [email protected]
Sent: 2/13/98 9:13:17 AM
Subject: Re: Failover for SO's with context
Steven,
The pattern choice between external resource vs SO is dependent on the
type
of transient data you want to backup. Probably the external resource
is
better
suited to high volumes of data. We have implemented the 'Backup SO'
pattern because our transient data volumes are rather low (which I
guess
must
be the most common case for global, transient data).
Whatever the choice you do :
- Be sure to enforce encapsulation for updating the transient data, in
order to
guarantee that any modification to your transient data is duplicated
on
the backup
SO or the external resource
- About performances, the CPU cost is fairly low for your 'regular'
application if you
take care to :
* use asynchronous tasks to update the external resource
or
* use events to notify the backup SO
Now it is true that you will have a network overhead when using
events,
as your
backup SO shall be isolated in a remote partition on a remote
server.
That is one good argument to select the Backup SO pattern for low
volumes of
transient data.
If you choose the 'Backup SO' pattern, you will also have to be
careful
not sending
any distributed reference to your Backup SO but only clones.
Anyway, the backup SO pattern works fairly well for low volumes of
data,
but requires lots of testings and a good understanding of events and
communication
across partitions.
Hope this helps,
Vincent Figari
On Fri, 13 Feb 1998 09:24:57 +0100 Steven Arijs <[email protected]>
writes:
We're going to implement a failover scenario for our application.
Unfortunately, we also have to replicate the state of our failed
service
objects.
I've browsed the Forte site and found a TechNote concerning this
(TechNote 11074).
In this TechNote they talk about a service object that is responsible
for updating all backup service objects when needed.
It seems to me that when I implement that way, I will be creating a
lot
of overhead, i.e. I will be doing a lot of stuff several times.
What will be the effects on my performance ?
The way with the least performance loss would be to use an external
resource that is updated. But what if this external resource also
fails
Is there any one who has already implemented a failover scenario for a
service objects with state ?
Any help would be appreciated.
Steven Arijs
([email protected])
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]