Everyone who uses a computer is aware of data synchronization or “sync” for short. It could be work documents sent to your home computer or music from your laptop music library to your phone or tablet. Either way, it’s having two or more sets

TACTIC’s aSync Technology

TACTIC’s aSync offers a revolutionary way for globally distributed companies to work on and share assets in real-time. By transmitting data and information instantly and asynchronously, TACTIC ensures that all data, and all transactions made on that data, are up to date no matter where in the world (and in what time zone) that data is worked on or stored. Check-ins, event triggers, undo, versioning, tasks, notes, and more are all supported.

Southpaw’s “aSync” technology avoids the possibility of data conflicts by making the synchronizing process dependent on the time at which the action was performed on the original system and not on the time it reaches the other systems. Additionally, the location for synchronization and type and collection of data that gets synchronized is all controlled by defined by rules set in the “aSync” configuration, so that no unnecessary or unneeded synchronizations of data take place. For enhanced protection, “aSync” stops its operation in the event of network complications and only resumes when the network is functional.

Within TACTIC, any action is recorded in what is called a “transaction”. This is Southpaw’s mechanism to repeat an action. A “transaction” is a compilation of XML defining the exact action performed in the system. An action is considered as anything performed in TACTIC including data modifications, additions, deletions and even ingestions.

At the time the action is performed, a “transaction” is generated and is stamped with the time at which it occurred. The “aSync” technology then packages the “transaction” in the form of an “aSync” job. This job is what is transferred to all other TACTIC systems that need to be synchronized. The “aSync” job only gets created for the data and TACTIC implementation locations they are to be synchronized to, based on the rules set in the configuration. Many “aSync” jobs can be generated and placed in a queue in preparation for transferral.

Due to the fact that this technology is dependent on the time at which the “transaction” occurred, no matter what order the “aSync” jobs arrive at the other systems, the “transactions” are performed sequentially according to the time at which they occurred on the original TACTIC system, hence, “aSynchronously” synchronizing the “transactions” on all other TACTIC implementations.

Synchronous Technology in the Industry

Synchronous technology is already existent in the industry. Data changes in one location or on one system are applied to the same data on all systems in all locations. This way, all users in any location get the most recent and up to date changes on any data and files available in the system. This is especially important when more than one user is working on the same set of data and files. Any changes are reflected almost instantaneously and other users can work on the latest state of the data and files. With up-to-date changes, it limits the possibility of time consuming conflict resolution for changes done on a file by different users, primarily because the file was either not updated fast enough or users did not have the most recent version.

A common way of synchronizing data is having a mechanism that copies or repeats the actions performed on one system to every other system. These actions are often performed on all other systems in the order that the mechanism transfers the action to the other system. Therefore, the technology is dependent on the time at which the mechanism delivers the action to the other systems.

However, what happens if the mechanism transfers the action out of order in which they were performed due to things like potential network interruptions? What if order is important due to data dependencies?

Existent technology also, as mentioned, involves the synchronization of all data changes across all systems in all locations. What if all the changes shouldn’t be synchronized? What if the data is only supposed to be synchronized to some systems in some locations and not others? Is that kind of control available?

Synchronizing the data could become problematic with the introduction of these data conflicts and lack of data synchronizing control. Suddenly, the technology that should be saving time and money is still costing both in data conflict resolution.

So what makes Southpaw’s synchronous technology so different from the existent technology?

The differences are twofold:

  • The way that the data changes and additions are synchronized in TACTIC
  • The amount of control given in synchronizing these changes and additions in TACTIC

The data synchronization dependency is not on the time at which the mechanism delivers the actions to other systems, but rather on the time at which the action was performed on the original system. In doing so, all actions get performed on all other systems in the order they were done on the original system, regardless of the time they arrive at the other systems.

Data change and addition synchronizations made in TACTIC can be controlled through the configuration of the technology. The configuration provides for a large degree of flexibility. Rules can be defined for varying levels of granularity, from the specific locations where the data is to be synchronized to the specific collection and type of data that is to be synchronized.

Each of these differences act as preventative measures against data conflicts. More to this point, even in the event of network issues, this technology is smart enough to stop the synchronizing process and continue from where it left off when the network connection is restored.

Categories: White Papers