Chetan,
Thank you for your prompt response. I'm not quite sure of the terminology, but I think we have only one node. All the data are stored in one repository in one file directory on one machine (for our initial implementation). This is the use case. We have a REST UI that provides access to digital asset data in the repository. Users can search or browse for assets, move them to different categories, change metadata or the assets themselves, and so on. They can also initiate a bulk upload of digital asset data from an FTP site to the repository, for which we set up and execute a separate job. The API supporting the UI has a Repository object for accessing the data, and the upload job has its own Repository object for the same purpose. Both use the same Repository and Session protocol as shown in the example code. The upload job blocks trying to create its Repository, as I have described. We are new to Oak and are still blundering about in the dark trying to figure out how to use it properly. Could you suggest the best approach to support our use case? Mike Harrison ________________________________ From: Chetan Mehrotra <[email protected]> Sent: Monday, June 5, 2017 11:08:43 PM To: [email protected] Subject: Re: Concurrrent use of Repositories On Tue, Jun 6, 2017 at 10:56 AM, Michael Harrison <[email protected]> wrote: > Is there any way to have concurrent access to the same data through two > repositories? SegmentNodeStore only supports single node setups. For multiple node setup aka cluster you would need to use DocumentNodeStore connected to Mongo or some database backed by DataStore Chetan Mehrotra DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.
