ERP: applicazioni tradizionali stateful con locking o applicazioni con browser stateless senza locking?

Nella valutazione di una soluzione ERP sono importanti due elementi: se opera con il controllo dello stato della sessione e se applica il locking dei record nel database gestionale.

Lo stato di una sessione (o di qualsiasi altra cosa) è la sua condizione o qualità di essere in un momento specifico.

Un'applicazione con stato conserva il contesto delle sue interazioni con utenti, sistemi o componenti.

Lo stato viene mantenuto con una soluzione di archiviazione durevole, in modo che l'applicazione sopravviva a un riavvio.

In sostanza la principale differenza tra applicazioni con stato e senza stato è che le applicazioni con stato (stateful) salvano le informazioni passate e presenti della sessione utente, mentre le applicazioni senza stato (stateless) no.

La gestione dello stato è essenziale per certi processi:

ERP (Enterprise Resource Planning) → deve sapere chi sei, che permessi hai, che operazioni stai facendo, cosa hai già fatto.
Applicazioni bancarie → lo stato della sessione e delle transazioni è critico.
Sistemi di prenotazione (voli, hotel) → lo stato delle prenotazioni deve essere tracciato.
eCommerce → carrello, storico degli ordini, sessione utente devono essere memorizzati.
CRM (Customer Relationship Management) → deve tenere traccia della relazione con ogni cliente.
App desktop (come Word, Excel, Photoshop, ecc.) → devono salvare continuamente lo stato dell’utente e delle sue sessioni.

ll locking (o blocco) di data record è una tecnica utilizzata nei database per garantire la coerenza dei dati in presenza di concorrenza tra transazioni.

In sostanza, il locking permette a un processo di acquisire il controllo esclusivo su un record, impedendo ad altri processi di accedervi contemporaneamente per evitare conflitti di modifica e mantenere l'integrità dei dati.

Perché il locking è importante:

Controllo della concorrenza → impedisce che due o più processi modifichino contemporaneamente lo stesso record, evitando conflitti e danneggiamenti dei dati.
Consistenza dei dati → garantisce che i dati siano sempre aggiornati e coerenti, anche in presenza di concorrenza tra processi.
Integrità dei dati → protegge i dati da errori e incoerenze dovute alla modifica simultanea.

Ecco qualche argomentazione per spiegare perché un sistema stateful con locking e arbitraggio è più affidabile e sicuro per certi contesti critici:

Integrità dei dati e concorrenza

Gli ERP stateless senza locking rischiano inconsistenze negli archivi in ambienti con molti utenti e processi concorrenti.
Le procedure di lock e arbitraggio garantiscono che non ci siano conflitti, modifiche simultanee o dati parziali: una vera trincea contro la corruzione dati.
In scenari industriali, magazzini robotizzati e applicazioni mission-critical, come quelle indicati in precedenza, questo è fondamentale per evitare errori costosi e pericolosi.

Controllo transazionale

Gli ERP stateful, o con sessioni persistenti, possono gestire transazioni complesse e multistep con rollback automatico in caso di errore.
Applicazioni stateless in browser spesso semplificano troppo, rinunciando a questo controllo fine, e rischiano di lasciare il sistema in uno stato incoerente in caso di interruzioni o errori.
Gli ERP stateful normalmente applicano le qualità ACID (Atomicità, Coerenza, Isolamento, Durabilità) che garantiscono l'affidabilità e l'integrità delle transazioni del database.

Queste proprietà assicurano che una transazione sia trattata come un'unità singola, che lascia il database in uno stato coerente, che le transazioni non interferiscano tra loro e che le modifiche apportate siano persistenti anche in caso di errore.
Il modello di transazione ACID classico (Two Phase Commit, commit/rollback), è impossibile da ottenere in un sistema completamente stateless.

Performance reale vs. apparente

A prima vista un sistema stateless in browser sembra più snello, ma in realtà un alto numero di daemon e utenti che fanno polling continuo o chiamate ripetute può saturare le risorse.
Un sistema stateful ben progettato, con locking e gestione efficiente delle risorse, può offrire performance più prevedibili e scalabili nel medio-lungo termine.

Debugging e manutenzione

Sistemi stateful facilitano logging, tracciamento e debugging, perché la sessione contiene lo stato necessario per diagnosticare problemi complessi.
Sistemi stateless puri possono rendere più difficile ricostruire il flusso esatto degli eventi, con conseguente aumento dei costi di manutenzione.

Esperienza d’uso e affidabilità percepita

L’utente finale vuole un sistema che funzioni senza perdere dati o richiedere continue riconnessioni o aggiornamenti manuali.
I dati visualizzati devono essere aggiornati e fruibili quando necessario, ad esempio: la disponibilità del prodotto è essenziale per una corretta gestione degli ordini da parte dell'operatore commerciale.
I dati visualizzati devono essere sicuri e certi; per questo scopo il locking, che impedisce sovrascritture accidentali, rende il sistema affidabile nel quotidiano anche se meno moderno nell’aspetto.

Conclusioni

Chi ha vissuto e risolto problemi di concorrenza e corruzione dati in ambienti mission-critical sa che scelte architetturali superficiali possono costare molto caro, in tempi, risorse e reputazione.

Si può quindi affermare che la leggerezza e la modernità di un ERP stateless e senza locking basato su browser sono allettanti, ma non sostituiscono la robustezza, la sicurezza e il controllo di un ERP con gestione dello stato e locking, soprattutto in ambienti complessi.

Un ERP tradizionale, non basato su browser, gestisce sempre lo stato e il record locking; è anche possibile sviluppare un ERP basato su browser che sia stateful, garantisca record locking e meccanismi di arbitraggio, come nel caso di SAP, ma richiede attenzione nella realizzazione e un’architettura sottostante (frontend-backend) adeguata e svincolata dal browser (server-centrica) che comporta, comunque, costi di implementazione non indifferenti.

In conclusione: nella scelta dell’ERP, tradizionale o in modalità browser, è fondamentale accertarsi che la logica applicativa sia comunque server-centrica, con gestione robusta dello stato, dei lock e delle transazioni.

(fonte: OpenAI ChatGPT- Giugno 2025)