You have to pass in a single application class to the initiator or
acceptor you create. This is really just a callback to the initiator
and acceptor (and maybe renamed at some point to better reflect this).
If you want to delegate to different application classes which you
create for each session, you certainly can do this.
The log records all messages (incoming and outgoing), and any
interesting errors or events that occur. It is strictly for logging
purposes and is not required by the session to do its job.
The store is necessary for the session, and it keeps sequence numbers,
session times, and messages queued for retransmission if necessary. The
usual tradeoffs between files and database apply here. Files will give
you superior performances. Databases allows you to query, take
advantage of various database tools, and makes it easier to build a
failover system. Your tolerance for disaster recovery vs speed is the
primary issue.
QuickFIX/J is a beta library and has not yet been given release status.
People are using it in that capacity, but you should be extra careful
with your testing. You can do a search of this mailing list for
QuickFIX/J to see what issues are currently being discussed.
--oren
Bryan Mazlish wrote:
> First I'd like to thank the Quickfix team for such a great product. I
> am just starting an implemetation of QuickFix/J and after spending a
> good deal of time sifting through the code and mail archives I still
> have the following questions that I hope someone can help with:
>
> 1- Will I encounter any problems if I use a separate Application class
> for every fix session that I create? The application object doesn't
> seem like it takes that much overhead and its seems logical to me to
> package everything fix-related inside of it from my application's
> perspective. The examples seem to imply that only one application
> object should exist, but I don't see any reason why that is necessary.
>
> 2- Am I correct that the log will log *everything* while the store
> only manages the sequence numbers? As a corollary, is there some
> benefit to using a database for either of these when it seems like
> files will be faster and easier to implement?
>
> 3- Finally, as per suggestion from an earlier post I downloaded the
> latest code (ie december 22) from the cvs source and built it rather
> than using the .zip binary. Please let me know if there is any
> instability in the code that I should be aware of.
>
> Thanks in advance for your help.
>
> Best regards,
> Bryan
>
>
|
