[Quickfixj-users] RE: [Quickfix-developers] QuickFix FailOver/Farming Support.

[Steve B. <sb...@sm...>]

> I don't really see why the no-op results in incorrect runtime=20
> behavior.  My view of the method is that it sets the state=20
> of the session to the persisted state.  In the case of the=20
> memory store, it is persisted into memory.  I=20
> could copy the state in memory from one place to another, it=20
> just happens that a no-op is a more efficient implementation. =20
> I don't really see it any different than if I refreshed against=20
> a database with store that is already in sync with the database. =20
> Nothing has changed (state wise), so it essentially acted like=20
> a no-op memory store refresh, but the end result is=20
> correct since the state of the session is correct.

Hi Oren,

Can you explain your view a little further? With a memory
store, how do you refresh the failed over session with the
session state that was previously stored in memory in a=20
separate process? When you say you could copy the state in
memory from one place to another are you talking about some
form of ongoing synchronization (vs. refresh at logon)
that updates the remote memory store every time the local
state changes?

> As to the name, I had always seen the settings as sitting in=20
> the [SESSION] section.  So I never thought that the settings=20
> required additional clarification any more then methods on=20
> the Session class are prefixed with Session.  Pretty much=20
> every setting is like this.  StartTime, EndTime,=20
> ConnectionType, ReconnectInterval etc. etc.  None of these=20
> settings explicitly state they are session settings, but=20
> that is implied by the name=20
> of the section.

OK, I understand. I agree about the shorter name. A
different question... did you envision the configuration=20
file eventually having section types other than "Session"=20
(and the pseudo-session for defaults)?

Steve
=20