I am working on POC of titan DB and following the GraphOfTheGods example .
TitanGraph g = TitanFactory.open(args[0]);
can any one please guide me when concurrent users will try to open the same instance of Titangraph ,whether everyone will get the same instance or different instance .
Thanks In advance
You will get a different instance of the graph everytime you load it in. This means different users can affect the graph simultaneously. I would recommend reading into Transactions if you going to have multiple users accessing and writing into the graph simultaneously. Be aware that Titan can autocommit changes as you do them. So your users may accidentally affect each other if this is not handled correctly.
Personally I use this:
titanGraph.tx().onClose(Transaction.CLOSE_BEHAVIOR.ROLLBACK);
to have more explicit control over when changes are committed.
Related
I am using Firebase's Realtime Database.
I am able to use my old device and permanently keep it on for checking if the host has left a party to therefore notify the users. However, this is inconvenient and there must be a simple server side solution.
I know how to code it (using .observe etc.) but I don't know where to run the code. The code will be on a loop to check if a host has left every 10 seconds (this is because the host may run out of battery so the database is not notified). Can I simply run it in functions somehow? Or using hosting?
The server code will send a request to the host, and if there is no response, the party has therefore been closed so it will tell the users.
Any help or pointers in the right direction are greatly appreciated.
If you have any questions, please ask!
It's not related to the iOS. Put your initial code into the viewDidLoad or init methods (depends on how do you write the code) and forget about it. Those methods are called once per an instance. For now Firebase works fine on your usecase. At least I don't have any wierd updates on the observe method. also you can specify what do you want to observe exactly in the Firebase (something like the new or last 15)
The solution to this was that even if the user left the app, they would still be in the party. I used user defaults so it can remember if the user was in a party so it can return them.
I also used Realtime Database triggers which can remove all information about a user with one action in the app (so all data gets removed, and not left behind, which would create a waste of unusable database memory).
My Goal:
Then database table was externally changed, I want to send WebSocket notification to clients.
Question:
Is there a "native" Sails.js way to track changes in database table populated via Model?
I only dabble in sails but I'm not aware of a way. You might make a "model-listener" service that utilizes your adapter of choice's socket/channel capabilities. You'll have to start the listeners at some point via a hook or in the bootstrap file.
The problem you're going to run into is determining if the event(create, update, drop/delete) was external or sails. I'm more familiar with PGSQL and know you can provide an application name to your connection and could include it in your publish message so your listener/subscribe handler can ignore non-sails related events.
PGSQL trigger/notify/listen
Event Triggers
Notify
Listen
MongoDB
Capped Collections
Tailable Cursors
Of course waterline supports more adapters than the two I've listed here but I tried to pick the two I assume are the most popular. I know this might be the answer you had hoped for but it might give you some ideas to try.
Sorry, I'm a new poster so I'll try to provide some links in comments if it will stackoverflow will allow me.
This question has been asked multiple times, here and here, and the answer to get this working is fairly straight forward: add an environmental variable to your bash_profile and all Meteor instances on your localhost will share that MONGO_URL.
What I've noticed however is that while this may be the case, there's quite a bit of latency in the "reactivity" of Meteor. I've tested this with two very lean Meteor apps, with empty collections. Inserting a document to a collection from one Meteor app, where my second app is querying that same collection and printing out a field from the documents does work, but there's a noticeable lag before it updates. I've ruled out the possibility of the collection insertion being the source of the lag (simple console.log callback on the client of the first app, logging the id of the newly inserted document).
My purpose for having multiple apps (two to be precise) sharing the same MongoDB is to separate an admin panel from a mobile app without going crazy regarding name-spacing and bloat. This configuration works, but I'm not sure it's the "proper" way of accomplishing the task, and it certainly seems to be causing a performance hit.
Any insight into this matter would be appreciated. Thank you!
EDIT: To clarify, the db URL I'm using is on my localhost, and isn't something hosted online.
When you use an external database, by default meteor will use periodic polling (every few seconds) in order to observe any changes. The delay you are experiencing is a result of this polling process. You can remove the delay and reduce your app's CPU usage by taking advantage of meteor's oplog tailing feature. In order to use it you will:
Get access to a mongodb instance with the oplog turned on.
Set the environment variable MONGO_OPLOG_URL so your app(s) can read the oplog.
Personally, I'd recommend compose.io for this. They provide exactly this as part of their basic elastic deployment. See this post for detailed instructions.
For users who wish to connect to the oplog created locally for you, you can obtain the URL via:
MongoInternals.defaultRemoteCollectionDriver().mongo._oplogHandle._oplogUrl
It should end up looking something like mongodb://127.0.0.1:3001/local
Ok, so I came to this company that recalled its software from an offshore, no-longer-extant entity. We all know the drill.
In looking at the nuts and bolts, I come across the 'lock' keyword. Googling, I find that Entity Framework does not support multi-threading.
My question is: How can I be 100% certain that the application is attempting to run in multiple threads? Is the existence of the 'lock' keyword enough?
Thanks.
If this is a ASP.NET/MVC web app and you have the lock keyword that is probably because the app is in IIS and IIS dispatches different user requests on different threads and therefore web app becomes multi-threaded.
In case of MVC - Controller is created per request and then it is processed on different thread. That leads to the need to lock something if two users at a time are going to access it.
If this is a desktop app and the lock is where data access happens it might be for similar purpose.
The lock keyword alone is not enough, they could be using it incorrectly after all. lock will just prevent more than one thread from entering the protected area at any one time. What is being protected by the lock? Data stored in a static variable is available to all users (threads) using the app and so should have controlled access.
This is related to Is there ReadOnly REST API key to a MongoLab database, or is it always ReadWrite and How does Mongolab REST API authenticate
I want to make it possible for unauthenticated users of my web app to create resources and share them. The created resource is an array of links ['link1', 'link2', 'link3'].
I'm looking at using MongoLabs directly from the client for this, which is possible through their REST api.
The problem though is that as far as I can see, if I do that, it would be impossible to prevent vandalists to clear out the entire collection rather easily.
Is this correct, and if so, is there a simple solution (without running a custom backend) to do something like this?
First off, you could create a "history", so if something goes wrong you can call on an easy command to restore records.
Secondly you might screen connected clients for abusive behavior; eg measure the number of delete or update commands in a certain timeset. If this get triggered you can call on your restoration process.
Note; i have no experience with MongoLabs whatsoever, but this - to me - would be a suitable safeguard in creating a public api.