Also known as Connected Workgroups, Replication is the feature where you can create multiple, working copies of the Vault database. The main reason you would want to do this is if you have multiple locations working on the same vault where your network latency is too large between locations. Replication speeds things up by allowing users to work exclusively with their local location. In the background, the data gets synchronized with the other site. This article will go into more details on this process because it has an impact on application development.
To understand Vault replication, you need to first understand the SQL Server replication since that is the underlying technology. As a rule, I try to avoid database details. But for replication, that rule is trumped by a bigger rule: Give developers the information they need to write Vault applications.
SQL Server Replication
In a nutshell, the concept is that you have separate databases on separate servers with the same data. This sounds simple, but it's actually one of the most complex things in database programming.
As you probably already know, most of the Vault data is in a database. So when you are viewing the Where Used on a part file, for example, you are just seeing a representation of a bunch of database rows. What SQL Server does is keep track of all the rows that change. These changes then get transferred to the other SQL Servers via a background process, and that's how data stays in sync.
One important thing about this transfer: it is not instantaneous. Even if you have a fast connection, you can expect there to be a delay of at least 1 minute before changes get transferred. This delay can also be longer if you have a slow connection or the network is under heavy load.
Here is where things start getting complex, because it's possible for data to be legal in one SQL Server but illegal when replicated. For example, in Vault, two people on different workgroups add a file called A.dwg to the same folder at the same time. Everything works fine until the data is replicated. Now you have two files with the same name in the same folder, which violates the rules on how Vault data should be structured. Problems like these are called conflicts.
There are various ways to deal with conflicts. For Vault, we took the approach of preventing conflicts from happening in the first place. We do this through the concept of ownership. If you want to make any edit in Vault, your workgroup needs the proper ownership. So my earlier example is not possible. You can only add A.dwg to a folder if your workgroup (aka. SQL instance) has ownership of the folder. The workgroup without ownership will get an error if the try to add a file to the folder (also, the folder will show up as locked).
The granularity of ownership varies depending on what you are working with. There's the concept of Entity Ownership, where a workgroup has control of specific entities. Files, folders, items and change orders are the only entities that can be owned in this way. Everything else uses the concept of Database Ownership, which means that a workgroup owns all data in the database which is not controlled via entity ownership. This covers things like property definitions, users, groups, categories, and so on. Mostly administrator settings are controlled this way.
Transferring ownership between two workgroups involves a handshake between the two servers.
- Workgroup A has ownership.
- Workgroup B requests ownership from A.
- Workgroup A changes ownership to B. But this change is only recorded in A's database.
- Data is replicated to B via the SQL Server background process.
- Workgroup B has ownership.
Some things to note about this process:
- Ownership transfer is not instant. The requesting workgroup needs to wait for a replication cycle before it has ownership.
- Between steps 3 and 4 things are in a strange state. A thinks B has ownership and B thinks A has ownership. Effectively, this means that nobody has ownership.
The last concept I want to talk about here is the lease concept. Basically a lease prevents ownership from being transferred for a set length of time. The rationale is that if you just grabbed ownership of something, you probably want to work on it for a while. You don't another workgroup grabbing it away from you a few seconds later. So when you transfer ownership, you set a lease period. Until that lease expires, nobody can change the ownership. Once the lease expires, it is still owned by the same workgroup. Only when another workgroup requests ownership will the ownership change.
I think by default you have a 1 day lease on entities you create. If you grab ownership from somewhere else, you get a 1 hour lease. If you have ownership of something, you can fully edit the lease. You can extend or shorten the lease time. You can remove the lease on an item or you can add a lease on something that does not have one. You can't edit the lease of something not owned by your workgroup.