On 8 May 2016 at 14:49, Eric24 <[email protected]> wrote: > Ah, very good. Thanks for that link (I don't think I had seen that page > before). A couple of questions about some of those 2.2 details: > 1) Is Hazelcast no longer used at all or are Hazelcast queues just not > used for intra-node communications? >
We still use HZ for: - discovery of nodes - configuration (HZ maps) - distributed locks But for intra-communications we drop them in favour of something custom: our binary protocol. Performance with 3 nodes are about 10x in v2.2 in comparison to v2.1! 2) Is client-side load balancing supported on the node.js driver (orientjs)? > OrientJs driver supports HA, so in case of crash it's able to automatically switch to another available node, but load-balancing is not yet implemented. > 3) In a distributed application (say, 3 ODB nodes) where multiple > end-client requests need to access and modify the same data (something like > a session object in a multi-server web application), I'm concerned about > consistency (i.e. end-client A updates a record when connected to node 1, > then end-client B queries that record when connected to node 2, but gets > stale data from before end-client A's update). I realize this is a common > problem for any distributed system, but I don't fully understand ODB's > consistency "guarantees". Assuming that writeQuorum is "majority", if node > 1 and 2 both successfully commit the update, it is my understanding that > end-client B will get the updated data (just as if it had connected to node > 1), but what if node 2 fails the update (but node 3 successfully commits, > thereby satisfying the writeQuorum)? What other scenarios should I watch > out for (I'm keying on the comment about consistency mentioned in relation > to per-request round-robin, but not per-connection round-robin, and I'm not > sure why this would be particularly different)? Also, if the update is to > just one record, is an explicit transaction of any kind needed here? > You're free to use or not transactions, so single create/update/delete can be executed distributed without transactions. Now in the scenario you pictured, a client could read a stale data during distributed transaction commit/rollback. We decided to leave it like this to avoid slowing down too much reads, but it's straightforward implementing the reads that wait for locked resources in order to guarantee a stale record is never read. Best Regards, Luca Garulli Founder & CEO OrientDB <http://orientdb.com/> > > > On Sunday, May 8, 2016 at 4:55:26 AM UTC-5, l.garulli wrote: >> >> In v2.2 is not supported anymore in the meaning that hotAlignment is >> ALWAYS on, look at: >> https://github.com/orientechnologies/orientdb-docs/blob/master/Release-2.2.0.md#distributed >> . >> >> Best Regards, >> >> Luca Garulli >> Founder & CEO >> OrientDB <http://orientdb.com/> >> >> >> On 7 May 2016 at 17:35, Eric24 <[email protected]> wrote: >> >>> Is hotAlignment working now in 2.2? >>> >>> On Wednesday, April 29, 2015 at 2:02:07 AM UTC-5, l.garulli wrote: >>>> >>>> Hi, >>>> Unfortunately hotAlignment is still not working, in the meaning that >>>> cannot guarantee 100% consistency of database. >>>> >>>> We are working with Hazelcast team for a more efficient solution (more >>>> reliable and much faster). This will be available in 2.2 (June 2015) or >>>> lately 3.0 (summer 2015). >>>> >>>> Lvc@ >>>> >>>> >>>> Best Regards, >>>> >>>> Luca Garulli >>>> CEO at Orient Technologies LTD >>>> the Company behind OrientDB >>>> http://about.me/luca.garulli >>>> >>>> >>>> On 28 April 2015 at 23:34, S. Monkey <[email protected]> wrote: >>>> >>>>> The documentation for distributed architecture ( >>>>> http://orientdb.com/docs/last/Distributed-Architecture.html) states >>>>> that hotAlignment should be set to false as true can lead to >>>>> inconsistency. >>>>> >>>>> Is this still the case in version 2.0.X (2.0.8 specifically)? >>>>> >>>>> If so, what is the correct way to configure a distributed database? If >>>>> autoDeploy is set to true then it appears that whenever starting a node >>>>> that joins a distributed cluster, the database is automatically deployed, >>>>> even if the node was previously a member of the cluster. For a large >>>>> database this could be problematic, but it seems this would be necessary >>>>> without a mechanism like hotAlignment. >>>>> >>>>> -- >>>>> >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "OrientDB" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OrientDB" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
