OpenLSD ENOpenLSD

Download at SourceForge.net
ConceptLogic Technical Aspects Future Plan Howto Benchmarks
Home OpenLSD OpenLSM OpenR66

Technical Aspects ML

 

  • Concept and Logic of ML

  • Technical Aspects of ML

  • Howto enter in production with ML

  • Perspective of ML

     

    The implementation uses the LSDOP table in the LSD database. This table registers operations like import, delete for one LSD index with a status and an IpPort target (OpenLSD Server from the component of this ML). The status says if it is done or in error or in wait.

     

    For an import, the document is first normally imported in the local OpenLSD Server with usual way. Then, when it is imported correctly, the Op table is filled with the LSD index for all IpPort target existing for this Legacy. The local one (where the import took place) is marked as done.

    For a delete, the document is first deleted normally from the local OpenLSD Server with the usual way. When correctly deleted, the OpTable is filled with the LSD index for all IpPort target as for import, the local one marked as done.

     

    The Op Handler is running outside of OpenLSD Server and can be running anywhere you want; however it should be closest to the database for efficiency. Every second (can be changed), the Op Handler looks at the Op Table to find some work to do:

    • For a delete, it sends the order of deletion of the document points by LSD index and its MD5. When done, the status in the database is changed.
    • For an import, it reads from one OpenLSD Server in done status and writes to one OpenLSD Server in waiting status, almost like a proxy. When done, the status in the database is changed for the written one.

    Once all operations are done for one LSD index, if they are all OK, the Op Handler removes those operations from the Op Table.

    The Op Handler looks at the database once and then wait that all operations are done (in ok or error status) and then it looks again at the database. So its handling is by step and no more than 500 items at a time.

     

    One point is to be cleared however: you must use the same kind of Legacy for all components of one Legacy in ML. That is to say if this Legacy is not using crypto, no components of this Legacy in ML will use the crypto. If this Legacy is using a crypto, every components of this Legacy in ML must use the same crypto key. The reason is for the delete support: the delete operation is permitted if the MD5 is correct. But if you use different behaviors for one LSD index, how can you have one unique MD5 for several crypto key for instance? You can’t, so the reason to use the same crypto key for one Legacy in Multiple Legacies support. It does not mean all of your legacies should use the same key or crypto mode, it is just the components of one specific Legacy at a time. If Legacy 1 uses crypto key 1, all OpenLSD Servers implementing Legacy 1 should use the same crypto key for the Legacy 1. If Legacy 2 uses no crypto key and is implementing on the same OpenLSD Servers, then all Legacy 2 will have no crypto key.

     

    One ML is created by making several Ip Port entries in the IpPort Table that implement one service attached to one Legacy. So adding the ML support for one existing Legacy is done by adding IpPort entries for the same Services which implement one Legacy.