< Previous by Date Date Index Next by Date >
  Thread Index  

[reSIProcate] Distributing the TransactionState class across mutliple stacks


Im looking at a way of making instances of TransactionState visible to mutliple stacks running on separate machines so that if one machine / stack fails part way through a transaction the rest of the transaction can be seamlessly handled by another. It will also provide load balancing by allowing any message to be handled by any stack instance.

Having spent a few days looking through the code and mapping out a class diagram and tracing the basic interactions between the classes when handing a message I'd like to share my ideas and see what you think, is it sound and have I overlooked anything?

The idea is to alter the TransactionMap class so that instead of storing TransactionState objects its local collection it stores them in a relational database to which all stacks have access. I would use Sun's Data Access Object 'blueprint' to persist & restore instances of TransactionState to the DB, so there would be a TransactionStateDAO object which is responsible for reading & writing TransactionState objects to the DB, as requested to do so by the modified TransactionMap.

Obviously at least initally whilst I prove the basic idea I want to keep thing as simple as possible, so objects referenced by TransactionState pose a slight problem as they would need to be persisted as well. To overcome this for the time being Im prooposing getting the TransactionStateDAO to do the following with the following variables linked objects:

mController: DAO doesnt write anything to DB for this when persisting, on restore, it sets it to the local stacks TransactionController.

msgToRestransmit: serialise as a string in the DB and create a new SipMessage object from the string when restoring

mDNSResult: unsure about this, havent worked out its purpose yet. Perhaps you could enlighten me?

mTarget & mResponseTarget: store IP addr & port in DB as simple strings & ints and create new object from those when restoring

mOriginalContact & mOriginalVia & mID: store as strings and create new objs from those strings when restoring

mTransactionUser: doesnt write anything to DB for this when persisting, on restore it sets it to the local stacks TU

The ultimate aim would be that ANY SIP message for a call could be received by ANY stack instance, as would be useful when building proxy servers.

Any thoughts welcome.

Regards
Andrew





_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/