Newsgroup: it.comp.java
Titolo: web e database

Ciao,
sto facendo una applicazione che gestisce l'editing di un database su web...
il problema è la modifica concorrente dei record: se uno passa in modalità
editing per quel record nessun'altro potrà entrare in modalità modifica;
questo lock però deve avere un timeout, scaduto il quale il record diventa
rieditabile. Il tutto chiaramente su Tomcat.
Esiste qualche "libreria" che sia sufficientemente indipendente dalla base
dati (ossia non dipenda dal DBMS che nel caso è Oracle)?!
Giovanni

 dati (ossia non dipenda dal DBMS che nel caso è Oracle)?!
Più che una libreria di accesso al database, per risolvere il problema
posto da te sarebbe necessario cambiare architettura: si potrebbe
utilizzare la piattaforma J2EE ed utilizzare le tecniche di gestione della
persistenza tramite gli EJB (Enterprise Java Bean). In questo modo
potresti risolvere in modo molto elegante il problema dei comandi
da inviare al database in quanto questa architettura mette a disposizione
metodi (java) di inserimento/modifica/cancellazione di record che
non dipendono dal database utilizzato. Ma questa architettura
richiede molte risorse sia tecnologiche che umane.
Spero di aver chiarito qualche dubbio, saluti Vincenzo.


Come metti il lock?
Se e' un lock del DBMS questo viene rilasciato non appena viene chiusa 
la connessione, pertanto sei costretto a tenerla aperta fra piu' 
richieste in modo da non perdere il lock.
Per far questo puoi inserire la connessione come attributo della sessione.
La connessione al DB verra' chiusa automaticamente (se non erro) insieme 
alla sessione (cosa che avviene già normalmente dopo un timeout 
specificato).
Altrimenti potresti implementare un HttpSessionListener per chiudere 
manualmente la connessione al DB quando la sessione viene distrutta.
Andrea Polci

 persistenza tramite gli EJB (Enterprise Java Bean).
Effettivamente a questo punto implementare EJB è un po' un lavoraccio (o
per lo meno lo è prenderci confidenza visto che mi sono quasi del tutto
oscuri).
Ti ringrazio se mi saprai dare un altro paio di dritte! :)
Giovanni
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 richieste in modo da non perdere il lock.
Io gestirei il lock in maniera logica nel DB magari in una tabella  del
tipo: ID_RECORD, LOCK_DATE, ID_LOCKER
Quando un utente richiede un record verifichi se l'ID figura tra quelli
bloccati ed eventualmente da quanto tempo. Nel caso il lock sia ancora
valido gli presenti il record in lettura, altrimenti lo cancelli e  lo
ricrei per il nuovo utente and so on ...
mauro


 ricrei per il nuovo utente and so on ...
Un suggerimento: verificare che il DBMS supporti le transazione e che 
prima di leggere la tabella dei lock si sia acquisito un lock (del DB) 
su di essa, altrimenti si pou' verificare che due diverse richieste 
pensino entrambe di aver acquisito il lock.
In alternativa occorre che il codice che accede alla tabella dei lock 
sia syncronized.
Andrea Polci

 HOWTO indica).
Ti rispondo per come la vedo io:
il lock dei record è una aperazione critica che conviene "sempre" demandare
al DBMS. Alcuni DBMS come Oracle non ti permettono neppure il lock
esplicito dei record. Se il tuo problema è assicurarti che nessuno modifichi
un
record durante la visualizzazione da parte di un client devi assicurarti,
prima
di fare un update, che il record che stai per modificare è identico a quello
che
hai letto. Credo che non ci siano altre alternative.
Questo comportamento è analogo ai client-dataset che alcune volte ho
implementato
con Delphi. In caso di "collisione" il sistema era in grado di fornire la
versione
originalmente letta dal client, la versione presente nel db e la modifica
che si
stava cercando di apportare. Tutto cìò era "gratis" poichè era implementato
da alcuni componenti di Delphi; nel tuo caso dovresti scriverti un paio di
classi specializzate.
Vorrei chiederti a questo punto che tipo di dati devi "proteggere"; mi sorge
il dubbio che con una servlet e qualche metodo "synchronized" puoi
risolvere il problema.
Saluti Vincenzo.

 risolvere il problema.
Sostanzialmente c'è una servlet che carica i dati di una tabella (una serie
di pubblicazioni: id, titolo, autore,...) e li rende accessibili tramite
beans ad una jsp (la collection di bean è esplorata con la tag di Struts
logic:iterate) che li visualizza in una <table> con degli href x la
modifica.
Cliccando su un link relativo ad una entry si richiama una servlet che
riceve l'id come parametro e carica in un bean i dati del record che vengono
visualizzati in una jsp che contiene una form. A questo punto il record
dovrebbe essere "lockato" finchè non c'è l'update.
L'accesso al db avviane tramite una classe che si occupa di estrarre i dati
e metterli nel bean. Questa classe è istanziata ogni volta che si accede ai
dati (quindi è istanziata una volta nella servlet che si occupa di estrarre
tutti i dati ed una volta nella servlet che si occupa di ricavare il record
da modificare) e riceve nel costruttore il DataSource che invece è
memorizzato come attributo di contesto dell'applicazione.
Oggi ho provato non JOTM che implementa le transazioni di JTA ma il "lock"
avviene in stile semaforo ossia se vado in modifica setto il lo stato della
transazione affinchè non si possa effettuare la stessa operazione (ossia la
modifica in generale)... il risultato è un lock sulla operazione di editing
che non equivale a ciò che volevo raggiungere! Il vantaggio è la gestione
"automatica" di un timeout della transazione che altrimenti dovrei
implementare io se dovessi applicare altri tipi di lock.
Spero di averti chiarito un po' lo scopo del progetto... se puoi farmi
sapere che pensi.
Giovanni