DB embedded per applicazione java standalone su filesystem di rete

[virus]

Come da oggetto.
Ho necessità/voglia di creare una applicazione scritta in codice java.
Tale applicazione si trova in un file di rete condiviso fra varie macchine con una JVM (versione 1.6) che possono avviare l’applicazione in locale.
Non ho possibilità di agganciarmi ad un server RDBMS, quindi devo lavorare con un database embedded che salva i dati sul filesystem creato.
Qualcuno ha qualche esperienza o suggerimento da offrirmi?

Mi sto documentando su JavaDB/Apache Derby e su SQLite.

Altro problema, un database del genere (o forse meglio dire 2 istanze di questo database) come si comporterà di fronte all’accesso ai file di rete di due client JVM?

[arkanoid]

Ciao Mario, è un piacere “rileggerti”.

Secondo me, SQLite se la può cavare assai egregiamente. Essendo Open Source e multipiattaforma, lo puoi installare in modo pratico e veloce praticamente ovunque.

In passato ho realizzato un mini-gestionale per l’ufficio dove lavoro. Al tempo non avevo la stessa esperienza che ho ora. Pur non utilizzando ORM e altre buone pratiche di programmazione, dopo 2/3 anni il programmino è ancora lì, che fa il suo sporco lavoro. A fine giornata, può capitare che, tramite esso, tre persone inseriscano dati nel database nello stesso momento. SQLite non mi ha mai dato problemi da questo punto di vista.

Non so in ambito Java come si comporti, ma con Python mi ha sempre lasciato soddisfatto.

Per maggiori dettagli, leggi http://www.sqlite.org/faq.html#q5:

We are aware of no other embedded SQL database engine that supports as much concurrency as SQLite. SQLite allows multiple processes to have the database file open at once, and for multiple processes to read the database at once. When any process wants to write, it must lock the entire database file for the duration of its update. But that normally only takes a few milliseconds.

[frafra]

Ti sconsiglio fortemente di condividere qualsiasi database serverless direttamente via rete utilizzando NFS o simili. Citando https://sqlite.org/whentouse.html:

[quote]Situations Where A Client/Server RDBMS May Work Better

[list=*]
*]Client/Server Applications

If there are many client programs sending SQL to the same database over a network, then use a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, file locking logic is buggy many network filesystem implementations (on both Unix and Windows). If file locking does not work correctly, two or more clients might try to modify the same part of the same database at the same time, resulting in corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.

A good rule of thumb is to avoid using SQLite in situations where the same database will be accessed directly (without an intervening application server) and simultaneously from many computers over a network./*]
[/list]
[/quote]

Come mai non puoi utilizzare Postgres o simili?
Se per qualche strano motivo necessiti di un database serverless, devi avere un programma che risieda sulla stessa macchina dove è memorizzato il database che faccia da tramite, come una piccola applicazione web o delle API REST.
Riguardo alla scelta del database serverless, non posso che consigliarti SQLite. E’ davvero straordinario. L’ho utilizzato per alcuni progetti, ha processato molte centinaia di migliaia di record su pc poco performanti senza alcun problema. E’ una piccola perla nel panorama del software libero.

Consiglio vivamente di guardare i seguenti video del creatore di SQLite (Richard Hipp):
[list=1]
]https://www.youtube.com/watch?v=ZvmMzI0X7fE/]
]https://www.youtube.com/watch?v=giAMt8Tj-84/]
[/list]

Tenete conto che il secondo risale al 2007 e molte cose sono cambiate.

La 3.9.0, appena uscita, ha pure il supporto a https://www.sqlite.org/json1.html e va https://www.phoronix.com/scan.php?page=news_item&px=SQLite-Release-Micro-Opts. Senza contare che ora supporta anche FTS5 e che è un database incredibilmente stabile, testato ed utilizzato praticamente ovunque.

[virus]

Troppo lungo spiegare la motivazione dell’assenza di un server SQL (che mi semplificherebbe non poco la vita!!!). Sono costretto lavorare serverless!

C’ho pensato parecchio e per il momento opterò per JavaDB/Apache Derby.
Ho studiato un po’, anche, la sua configurazione server-client e purtroppo non potrò utilizzarla. Quindi il DB deve essere serverless.

La scelta di questo è per avere, al momento, la portabilità dell’applicazione su differenti sistemi operativi senza dover ricompilare o creare pacchetti differenti per differenti S.O., cosa che sono costretto a fare con SQLite.

[frafra]

Eh, no, eh, così non vale! Ci chiedi consigli, fai l’esatto contrario e non ci spieghi il perché!

Comunque non farlo. Davvero. Condividere database via NFS/Samba è una pessima idea perché rischi seriamente ti si blocchi tutto per un lock non rilasciato correttamente. Se proprio non vuoi un server SQL usane uno HTTP per far partire le procedure con i parametri che vuoi. Un server ce lo devi aver sempre: SQL, HTTP, TCP o NFS. Con NFSv4 le cose sono migliorate, ma davvero, non è la strada da seguire.

Inoltre Derby, a differenza di SQLite, pare non supportare connessioni multiple in modalità embedded:

If you need to access a single database from more than one Java Virtual Machine (JVM), you will need to put a server solution in place. You can allow applications from multiple JVMs that need to access that database to connect to the server. The Derby Network Server is provided as a server solution. For basic information on starting and using the Network Server, see Getting Started with Derby. See the Derby Server and Administration Guide for more information on the Network Server

Fonte: https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/devguide/cdevdvlp20458.html

Di conseguenza per farlo funzionare dovresti ogni volta aprire e chiudere una connessione. Non hai concorrenza, dovresti riprovare di tanto in tanto per vedere se la risorsa si è liberata, le performance sarebbero terribili e sicuramente si bloccherebbe prima o poi, o per un problema di locking lato NFS o perché la tua app ha lasciato aperta la connessione al database.

[virus]

frafra non mi devi convincere che un server SQL è meglio di un serverless e che condividere un database su un filesystem condiviso è una scelta inappropriata.

Purtroppo nell’ambito dell’azienda in cui lavoro non sono io l’amministratore di rete e non c’è verso/non ci sarà verso di ottenere un database su server dedicato (la procedura burocratica è troppo lunga).

Ho necessità di avere una applicazione personalizzata per la gestione di alcuni dati. Cambio in continuazione pc e fortunatamente hanno previsto un filesystem condiviso (ma il bello è che c’è anche una cartella privata per ogni utente) e su ogni macchina è presente una JVM.
Diventa una scelta quasi obbligata l’uso del db serverless ospitato nel filesystem di rete.

La scelta del Java ricade invece per evitare di dover compilare il codice per più S.O. lo scrivo una volta (retrocompatibile) e poi basta, non ci penso più e l’applicazione gira su qualsiasi macchina dell’azienda.
Mi sarebbe piaciuto usare python, ma dovrei installare python su ogni pc e servono i diritti di amministratore (cosa che non ho).

Il top, in assoluto, come dici tu, sarebbe avere una applicazione web con un server web! Mi sarebbe anche più agevole la programmazione in Php (che conosco benino) con PostrgreSQL o MySql o MariaDb, che conosco meglio, ma davvero è una opzione impraticabile al momento.

So per certo che nella intranet alcuni servizi sono forniti tramite Tomcat…l’applicazione che sto creando usa il pattern MCV quindi il codice dovrebbe essere più facilmente riutilizzabile in futuro

[frafra]

Eheheh

Capisco che ti trovi in una situazione complicata, ma… Beh, ho già detto il perché credo possa portarti solo che problemi in futuro, quindi passiamo oltre

Non servono i permessi di amministratore per poter utilizzare Python. Detto questo, usa pure Java, non credo sia questo il problema.

Se pensi sia possibile fare una applicazione web o almeno delle API web, non posso che consigliarti questa strada, a prescindere dalla scelta Derby vs SQLite (anche se preferisco il secondo). Non voglio essere noioso, ma credo che alla lunga potresti evitare a te stesso tanti problemi. Potresti utilizzare http://djangoproject.com/

Se pensi non sia fattibile, valuta di esporre almeno delle API per delle procedure. Il tuo client richiederebbe una risorsa HTTP tipo http://server/procedura/parametro1/parametro2/. Qualcosa tipo: https://github.com/alixaxel/ArrestDB