Thread: [Quickfix-developers] QFJ: Acceptors and SessionQualifiers
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: Shepheard, T. (London) <Tob...@ml...> - 2005-10-06 14:58:39
|
NB: This is using QuickFIX/J (1.0.0-beta1) with a minor fix from CVS for FileLog.java I came across a problem when running as an Acceptor with the JDBC message store (JDBCStore.java), and the fact that the SessionQualifier is null for Acceptors, but is required in the database tables. See http://www.quickfixengine.org/bugtracker/bug.php?op=3Dshow&bugid=3D115 Am I missing something here or is this a problem with QFJ - and are SessionQualifiers really needed? From what I can see they look like they're meant to be optional for initiators, and meaningless for acceptors, but I'm not at all sure. As far as I can see I've got two options - either add a session qualifier to the acceptor config, or alter the DB and JDBCStore code to not require a session qualifier (which has a rather large impact due to the primary key changes that would entail). I hope someone can advise! Many thanks, Toby -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the = sender, delete it and do not read, act upon, print, disclose, copy, = retain or redistribute it. Click here for important additional terms = relating to this e-mail. http://www.ml.com/email_terms/ -------------------------------------------------------- |
|
From: Steve B. <st...@te...> - 2005-10-07 07:31:29
|
Hi Toby, The session qualifier is logically part of the primary key that uniquely identifies a session. Multiple sessions can have the same begin string, target/sender company identifiers. This is also the way the QF C++ code is designed. You won't be able to remove the "not null" constraint for session qualifier without removing it from the primary key -- and that probably isn't a good thing. The SQL schema used by QFJ is the same one that the QF C++ code uses. However, there might be some additional issues in QFJ because it supports any JDBC database rather than just MySQL. Which database are you using? Is the session qualifier a Java null or an empty string? Some databases will convert an empty string to a NULL value when inserting a row into the database, so either way it could be a problem in some cases. Oren, any additional comments? Steve Shepheard, Toby (London) wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > NB: This is using QuickFIX/J (1.0.0-beta1) with a minor fix from CVS > for FileLog.java > > I came across a problem when running as an Acceptor with the JDBC > message store (JDBCStore.java), and the fact that the SessionQualifier > is null for Acceptors, but is required in the database tables. See > http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=115 > > Am I missing something here or is this a problem with QFJ - and are > SessionQualifiers really needed? From what I can see they look like > they're meant to be optional for initiators, and meaningless for > acceptors, but I'm not at all sure. > > As far as I can see I've got two options - either add a session > qualifier to the acceptor config, or alter the DB and JDBCStore code to > not require a session qualifier (which has a rather large impact due to > the primary key changes that would entail). I hope someone can advise! > > Many thanks, > Toby > -------------------------------------------------------- > > If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ > -------------------------------------------------------- > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Oren M. <or...@qu...> - 2005-10-07 13:36:55
|
Yeah, the way it is implemented right now, is that any sessionID
"without" a session qualifier, has a blank string as the qualifier.
Which as noted allows us to make it part of the primary key. In the
java wrappers for the C++ engine, the constructor for a sessionID
without a qualifier looks like this:
public SessionID(String beginString,
String senderCompID,
String targetCompID) {
create( beginString, senderCompID, targetCompID, "" )
}
So you can see that a blank string is being assigned. It looks like
QuickFIX/J does the same thing with its sessionID. So far I'm not
aware of any problems this caused with the direct SQL implementations
I've seen (MySQL, PostgreSQL, MSSQL). If this is a problem, I'd be
surprised if it was an acceptor only problem, since most initiator
sessions are also created with blank session qualifiers unless they
are specifically added. Are there really databases you know of that
cannot differentiate between a NULL and a blank string?
--oren
On Oct 7, 2005, at 2:31 AM, Steve Bate wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Toby,
>
> The session qualifier is logically part of the primary key that
> uniquely identifies a session. Multiple sessions can have the
> same begin string, target/sender company identifiers. This is
> also the way the QF C++ code is designed. You won't be able
> to remove the "not null" constraint for session qualifier
> without removing it from the primary key -- and that probably
> isn't a good thing.
>
> The SQL schema used by QFJ is the same one that the QF C++
> code uses. However, there might be some additional issues in
> QFJ because it supports any JDBC database rather than just
> MySQL. Which database are you using? Is the session qualifier
> a Java null or an empty string? Some databases will convert
> an empty string to a NULL value when inserting a row into the
> database, so either way it could be a problem in some cases.
>
> Oren, any additional comments?
>
> Steve
>
>
> Shepheard, Toby (London) wrote:
>
>> QuickFIX Documentation:
>>
> http://www.quickfixengine.org/quickfix/doc/html/index.html
>
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> NB: This is using QuickFIX/J (1.0.0-beta1) with a minor fix from CVS
>> for FileLog.java
>>
>> I came across a problem when running as an Acceptor with the JDBC
>> message store (JDBCStore.java), and the fact that the
>> SessionQualifier
>> is null for Acceptors, but is required in the database tables. See
>> http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=115
>>
>> Am I missing something here or is this a problem with QFJ - and are
>> SessionQualifiers really needed? From what I can see they look like
>> they're meant to be optional for initiators, and meaningless for
>> acceptors, but I'm not at all sure.
>>
>> As far as I can see I've got two options - either add a session
>> qualifier to the acceptor config, or alter the DB and JDBCStore
>> code to
>> not require a session qualifier (which has a rather large impact
>> due to
>> the primary key changes that would entail). I hope someone can
>> advise!
>>
>> Many thanks,
>> Toby
>> --------------------------------------------------------
>>
>> If you are not an intended recipient of this e-mail, please notify
>> the
>>
> sender, delete it and do not read, act upon, print, disclose, copy,
> retain or redistribute it. Click here for important additional terms
> relating to this e-mail. http://www.ml.com/email_terms/
>
>> --------------------------------------------------------
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by:
>> Power Architecture Resource Center: Free content, downloads,
>> discussions,
>> and more. http://solutions.newsforge.com/ibmarch.tmpl
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
|
|
From: Steve B. <st...@te...> - 2005-10-07 14:41:05
|
Oracle treats an empty string as a null. :-( Steve Oren Miller wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > Yeah, the way it is implemented right now, is that any sessionID > "without" a session qualifier, has a blank string as the qualifier. > Which as noted allows us to make it part of the primary key. In the > java wrappers for the C++ engine, the constructor for a sessionID > without a qualifier looks like this: > > public SessionID(String beginString, > String senderCompID, > String targetCompID) { > create( beginString, senderCompID, targetCompID, "" ) > } > > So you can see that a blank string is being assigned. It looks like > QuickFIX/J does the same thing with its sessionID. So far I'm not > aware of any problems this caused with the direct SQL implementations > I've seen (MySQL, PostgreSQL, MSSQL). If this is a problem, I'd be > surprised if it was an acceptor only problem, since most initiator > sessions are also created with blank session qualifiers unless they are > specifically added. Are there really databases you know of that cannot > differentiate between a NULL and a blank string? > > --oren > > On Oct 7, 2005, at 2:31 AM, Steve Bate wrote: > >> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ >> html/index.html >> QuickFIX Support: http://www.quickfixengine.org/services.html >> >> Hi Toby, >> >> The session qualifier is logically part of the primary key that >> uniquely identifies a session. Multiple sessions can have the >> same begin string, target/sender company identifiers. This is >> also the way the QF C++ code is designed. You won't be able >> to remove the "not null" constraint for session qualifier >> without removing it from the primary key -- and that probably >> isn't a good thing. >> >> The SQL schema used by QFJ is the same one that the QF C++ >> code uses. However, there might be some additional issues in >> QFJ because it supports any JDBC database rather than just >> MySQL. Which database are you using? Is the session qualifier >> a Java null or an empty string? Some databases will convert >> an empty string to a NULL value when inserting a row into the >> database, so either way it could be a problem in some cases. >> >> Oren, any additional comments? >> >> Steve >> >> >> Shepheard, Toby (London) wrote: >> >>> QuickFIX Documentation: >>> >> http://www.quickfixengine.org/quickfix/doc/html/index.html >> >>> QuickFIX Support: http://www.quickfixengine.org/services.html >>> >>> NB: This is using QuickFIX/J (1.0.0-beta1) with a minor fix from CVS >>> for FileLog.java >>> >>> I came across a problem when running as an Acceptor with the JDBC >>> message store (JDBCStore.java), and the fact that the SessionQualifier >>> is null for Acceptors, but is required in the database tables. See >>> http://www.quickfixengine.org/bugtracker/bug.php?op=show&bugid=115 >>> >>> Am I missing something here or is this a problem with QFJ - and are >>> SessionQualifiers really needed? From what I can see they look like >>> they're meant to be optional for initiators, and meaningless for >>> acceptors, but I'm not at all sure. >>> >>> As far as I can see I've got two options - either add a session >>> qualifier to the acceptor config, or alter the DB and JDBCStore code to >>> not require a session qualifier (which has a rather large impact due to >>> the primary key changes that would entail). I hope someone can advise! >>> >>> Many thanks, >>> Toby >>> -------------------------------------------------------- >>> >>> If you are not an intended recipient of this e-mail, please notify the >>> >> sender, delete it and do not read, act upon, print, disclose, copy, >> retain or redistribute it. Click here for important additional terms >> relating to this e-mail. http://www.ml.com/email_terms/ >> >>> -------------------------------------------------------- >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: >>> Power Architecture Resource Center: Free content, downloads, >>> discussions, >>> and more. http://solutions.newsforge.com/ibmarch.tmpl >>> _______________________________________________ >>> Quickfix-developers mailing list >>> Qui...@li... >>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >>> >> >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: >> Power Architecture Resource Center: Free content, downloads, >> discussions, >> and more. http://solutions.newsforge.com/ibmarch.tmpl >> _______________________________________________ >> Quickfix-developers mailing list >> Qui...@li... >> https://lists.sourceforge.net/lists/listinfo/quickfix-developers >> >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
