I am evaluating GridGain 6.1.8. My objective is to have only one node in the grid (called leader) doing some specific job. The requirements are:
The leader node must be elected automatically by the grid.
Only one node could be the leader at a time.
If the leader dies the grid must elect another node as the leader.
How to implement it?
Starting with GridGain 6.2.0-rc2 release GridGain has GridProjection.oldest() method which can be used as a leader. It satisfies exactly the requirements you are listing.
Also, you can find more information in this post: Gridgain leader election pattern
Related
So I've been tasked with developing a POC for my company and have been learning about Corda. I think I understand the overview of Corda and a few details but I came across something that I don't quite understand. To illustrate, let's use the IOU example that the tutorial uses.
In that case, let's say I have two parties: Alice and Bob. Alice borrows $20 from Bob. This is correctly recorded in both their vaults and DB.
Now, let's say Bob is a bad actor and manually updates the information on his side (including associated hashes for the transaction) so that the transaction states that Alice borrowed $30 instead of $20.
So here are my questions:
Are there any safeguards built into Corda to prevent Bob from arbitrarily changing the data on his end?
If he is successful in mutating the facts on his end, how does the network decide who is correct in the future when Alice and Bob both present mutually exclusive transaction histories?
In a similar use case, imagine there is a fact that is initially shared between multiple parties, then is legitimately marked as only concerning one party, and then is again shared multiple (potentially different) parties. In this case, what would happen if the fact were to be illegitimately mutated during the single party access phase of the fact's lifespan?
Thanks in advance to all the people that help clear this up!
This will be specified in the smart contract you setup with the counterparty when instigating the trade. Cobra will not settle your distributes since this defeats the whole purpose of the platform.
I wonder if there is a way to observe changes in the whole graph, instead of subscribing to changes on one particular node. I was not able to find an answer reading the Docs/Howtos at gun.eco/docs
Lets say you build a real-time mind-mapping application, so basically a graph/tree structure.
If I add a new node - at some place - to the graph I want to update my UI
If I remove a node or a whole subtree ...
The 2. scenario is a a general concern:
How can I delete multiple nodes together with all related edges ?
Copied from conversation with Gun Community:
First Answer:
To answer the 1st, You could have an index node that you subscribe to unsing gun.get(node).on(callback, changesOnlyFlag). New nodes would trigger the update function, where you will check what that node might be related to in your application.
To answer the 2nd, Delete in a decentralized system is hard. (Google tombstone problem) In Gun deletes are handled by putting null to an object, which cuts all edges from that item and it becomes unreachable from a traversal standpoint. (Although you can still get the children nodes by their soul (UUID of node), or via the index node that you might add all children too, by default)
Second Answer:
https://gun.eco/docs/API#open describes an additional module you can require to open the whole graph. Which can be used to track changes, with slight modifications to the code.
In the Corda-example, if we want to add custom validating code, we can override checkTransaction() in the responder codes to make sure the IOU is above a certain threshold. This assumes that all responders are agreeable to that threshold.
What if we allow every lender to set their own threshold. In that case the threshold becomes a variable. To address this, I created a UI that directly publishes the threshold (an integer) to the database. However I am finding it hard to extract the value and passing it to a threshold variable in the flow code. Is there a better way? If this works, I can quarantine more variables and using the UI for individual nodes, I get to set custom parameters (into the database) used in the validation of the state in the Tx.
The easiest way to achieve this is to provide a different implementation of the flow for each node. For example, if you had an AcceptTxBasedOnThreshold flow, you'd create several implementations:
One AcceptTxBasedOnThreshold flow implementation for NodeA, which perhaps has a threshold of 10
One AcceptTxBasedOnThreshold flow implementation for NodeB, which perhaps has a threshold of 20 instead
And so on for any additional nodes...
You'd then create several CorDapps:
The first CorDapp would include the shared state and contract definitions that everyone uses. You'd install this CorDapp on every node. This CorDapp wouldn't include any flow definitions
You'd then create an additional CorDapp for each node:
A CorDapp with only NodeA's AcceptTxBasedOnThreshold flow. This CorDapp would only be installed by NodeA
A CorDapp with only NodeB's AcceptTxBasedOnThreshold flow. This CorDapp would only be installed by NodeB
There is one example to explaining associations in UML.
A person works for a company; a company has a number offices.
But I am unable to understand the relationship between Person, Company, and Office classes. My understanding is:
a company consists of many persons as employees but these classes exist independently so that is simple association with 0..* multiplicity on Person class' end
a company has many offices and those offices will not exist if there is no company so that is composition having Company as the parent class and 0..* multiplicity on Branch class' end.
But I am not sure of 2nd point. Please correct me if I am wrong.
Thank you.
Why use composition or aggregation in this situation at all? The UML spec leaves the meaning of aggregation to the modeler. What do you want it to mean to your audience? And the meaning of composition is probably too strong for this situation. Thus, why use it here? I recommend you use a simple association.
If I were you, I would stay truer to the problem domain. In the world I know, Offices don't cease to exist when a Company goes out of business. Rather, a Company occupies some number of Offices for some limited period of time. If a Company goes out of business, the Offices get sold or leased to some other Company. The Offices are not burned to the ground.
If you aren't true to the problem domain in an application, then the shortcuts you take will become invalid when the customer "changes the requirements" for that application. The problem domain doesn't actually change much, just the shortcuts you are allowed to take. If you take shortcuts to satisfy requirements in a way that are misaligned with the problem domain, it is expensive to adjust the application. Your customer becomes unhappy and you wind up working overtime. Save yourself and everyone the trouble!
While Jim's answer is correct, I want to add some extra information. There are two main uses for aggregation
Memory management
Database management
In the first case it gives a hint how long objects shall live. This is directly related to memory usage. If the target language is one which (like most modern languages) uses a garbage collector, you can simply ignore this model information.
In the second case, it's only partially a memory question. A composite aggregation in a database indicates that the aggregated elements need to be deleted along with the aggregating element. This is less a memory but in most cases a security issue. So here you have to think twice.
A shared aggregation however has a very esoteric meaning in all cases.
I am designing a graph database for eligibility rules. Some eligibility rules require that a user select 2 particular products (Product A and Product B) to qualify for Product C.
Is it possible to create a graph edge with 2 starting nodes?
I would think this would break what I think is the fundamental building block of a graph db - its adjacency list. But if this was possible, it would be very powerful for my application.
Update 6/16
More specifically, I'm looking to create a directed edge with 2 starting nodes, and 1 ending node. So, in biz rules terms: IF Node=A AND Node=B THEN Node=C. The real world relationship is this: If customer buys Product A and Product B, then customer qualifies for Product C.
Usually, to model a hypergraph in Neo4j, you end up creating an intermediate "group node" that connects all of the nodes you want to connect, then bridging off of that node to the other node. It's not a true hypergraph, but rather a representation of a hypergraph using the tools provided.
Here's an example:
http://www.markhneedham.com/blog/2013/10/22/neo4j-modelling-hyper-edges-in-a-property-graph/
Yes you can have multiple starting nodes in Neo4j, not sure about other graph db.
START a=node(0), b=node(1)
RETURN a,b
You should refer to http://docs.neo4j.org/chunked/stable/query-start.html for more details. Starting from Neo4j 2.0 start node is optional, Cypher will try and infer starting points from your query based on label and where clause.
Edit
I have edited the answer based on the updated question. What you need is a hypergraph. As Wes Freeman mentioned, to model a hypergraph Neo4j you will need to create an intermediate node that connects your other two nodes and the the third node. In you scenario a user will have a PURCHASED relationship with the two products(A and B) kinda like (:User {Id: 1})-[:PURCHASED]->(:Product {Name:A}). Then you will have to create an intermediate node like ProductQualifier (I am very bad at naming things) having a relationship from user like (:User {Id:1})-[:QUALIFIES]->(:ProductQualifier {Id:1}). The Product qualifier will then have 3 relations, two to Product A and B respectively and a third to Product C,
(:Product {Name: 'B'})<-[:HAS]-(:ProductQualifier {Id:1})-[:HAS]->(:Product {Name: 'A'})
(ProductQualifier {Id:1}-[:ELIGIBLE]->(:Product {Name: 'C'})
This ought to do what you want.
A second approach that you can take is use a database that inherently supports hypergraphs, something like Hypergraphdb, thus discarding the burden of creating extra node. I haven't had any occasion to use it though I wanted to try it out for quite some time, so I don't know in much details about its API's or its limitations, however it is fairly well known graph database.
Note: As mentioned I am very bad at naming things. You should probably change the label names to more suitable to your business model.