USAGE

It may be helpful to consider a few helpful notes on how your application may interact with ARCS. Your application may warrant some of the following scenarios or some variation of them.

• If a given user for a given application can launch multiple application sessions, you may want to distinguish between those “users” by adding a unique identifier to each of the users, in order to form appropriately unique UserIDs. This will ensure that those user sessions are also in competition with one another.
• If your application crashes and it can somehow detect that the next time it is launched for the same user that crashed, you could call CheckIn and if it returns 1, you probably wouldn’t want to call Begin, since it is apparent that all of your previous resources are still appropriately bound. (Begin always starts completely anew and so may or may not be appropriate.)
• Even if you already have a given resource bound, when you’re about to write data to your application’s database, it is prudent to call Bind first in order to see if you still have the resource bound (suppose your application hadn’t run CheckIn because it lost connectivity for too long and then some other user came along and was able to steal the resource). For a write that takes so long that the threshold could theoretically be surpassed during the write, it would also be a good idea to call Bind just before the actual writing. Even when it is the case that a given resource is not bound, a call to Bind before writing is prudent. Upon receiving a successful result from Bind, you should check that the data you originally read matches what is currently in the database before committing the write.
• Notice that it is actually possible to steal a resource from some other user (by first calling Release for the applicable UserID and ResourceID). While this may not be common practice, it may be warranted by a given type of application.