2013-08-11 9 views
13

Sto scrivendo la logica lato server per un'app Meteor che deve aggiornare lo stato in memoria in risposta alle richieste del client. Questa applicazione richiede forti garanzie di concorrenza, in particolare, voglio essere sicuro che sia eseguito un solo aggiornamento alla volta.Che cos'è il modello di concorrenza di Meteor?

Sto cercando di capire se il modello di concorrenza di Meteor lo supporta. La documentazione menziona che Meteor è multithread (che sarebbe un problema), ma dopo aver cercato in giro, ho l'impressione che Meteor usi effettivamente fibre (thread esplicitamente programmati). Se è vero, allora sono al sicuro finché la parte del mio codice che deve essere eseguita atomicamente non fa alcuna chiamata Meteor (che coinvolge IO e quindi produce il blocco dell'esecuzione).

È questo il caso? Dove posso trovare ulteriori informazioni sul modello di concorrenza di Meteor?

+0

Penso che dovresti implementare i blocchi da solo per te nella memoria in-memory o puoi usare le operazioni atomiche di mongo. – Denis

+0

Se è utile, la documentazione per la libreria delle fibre è [qui] [1] [1]: https://github.com/laverdet/node-fibers –

+0

@Denis Se posso implementare i blocchi in memoria perché non-IO, le operazioni non-yield sono atomiche, quindi non ne ho nemmeno bisogno per questa applicazione. In ogni caso, voglio sapere in che modo la concorrenza in Meteor funziona per informazioni future. Questa roba dovrebbe essere chiaramente documentata da qualche parte; non lo è. Probabilmente finirò per passare attraverso il codice sorgente di Meteor. – disatisfieddinosaur

risposta

11

Va bene, ho guardato attraverso la fonte Meteor ed ecco come funzionano le cose:

1) Sul lato server, Meteor utilizza esclusivamente fibre di gestire la concorrenza. Le fibre sono come fili, tranne che il contesto deve essere esplicitamente prodotto. Questo rende più facile ragionare sulla concorrenza, al costo (potenziale) di alcune fibre che affamano gli altri.

2) Tutte le chiamate a Meteor.call, Meteor.setInterval e qualsiasi operazione di raccolta sono avvolte in fibre. Ciò significa che tutte queste chiamate danno un contesto.

3) Inoltre, qualsiasi utilizzo delle rese del modulo fibre/futures.

Il risultato di questa struttura è che se si desidera scrivere operazioni atomiche, è sufficiente evitare di accedere agli oggetti forniti da Meteor framework nel blocco di codice che si desidera rendere atomico. Se questo blocco ha realmente bisogno di un accesso DB, è possibile implementare i blocchi in memoria senza problemi, ma per la mia applicazione questa conoscenza è sufficiente. La mia funzione di aggiornamento principale ha solo bisogno di essere chiamata con tutti i documenti necessari da Mongo già letti.

1

Dalla documentazione di meteore:

In Meteor, il codice del server viene eseguito in un singolo thread per ogni richiesta, non nello stile tipico di callback asincrona del Nodo. Troviamo che il modello di esecuzione lineare si adatta meglio al tipico codice server in un'applicazione Meteor .

http://docs.meteor.com/#structuringyourapp

Qualcuno sa le implicazioni sulle prestazioni di questo?

Problemi correlati