Discussion :

[Pwill]

Bonjour,

Je suis désolé je ne sais pas ou poster... entre postgresql/J2EE/et java...
Le code est en java, donc je poste ici. Le titre n'est surement pas explicite !

J'ai une application J2EE qui permet à l'utilisateur de travailler à partir de d'une base de données PostgreSql.
Il me faudrait implémenter une classe permettant de travailler à partir de "données personnelles".

Après courte réflexion, je me suis lancé dans l'ajout de données temporaires dans une table temp. Cette table recevrait les données à partir d'un fichier puis l'utilisateur travaillerait à partir de cette table (elle contient au minimum 171k lignes et monte jusqu'à 10x 171k).
Dès qu'un utilisateur envoit de nouvelles données, on supprime les anciennes...
Seulement cela poserait un problème lors d'accès concurrents. (cela ne devrait pas arriver tous les jours, mais bon)
X envoit ses données, le commit est réalisé. Y arrive juste après et écrase les données de X ? que se passe t-il si X n'a pas commencé à travailler ?

Voyez-vous un moyen de poursuivre dans cette voie et de gérer ces accès concurrents ?

Sinon, je pourrais éventuellement créer une table temp pour chaque session, chaque session bosse dessus, et il faudrait virer la table lorsque la session est détruite.
Cette 2ème solution est-elle envisageable ?
Mais dans ce cas... le problème de l'espace disque peut se poser non ?

Merci d'avance, n'hésitez pas à faire part de vos remarques

[Stane]

Juste une idée ...

Pourquoi pas une table "temporaire" permanante pour tous les utilisateurs avec pour la clé la session en plus ?

Il faut bien sur prevoir la suppression après le commit pour la session et pas la suppression totale, initialisation eventuelle au demarrage de WEBAPP

[Pwill]

J'ai une clef qui s'incrémente a chaque ajout de ligne. Donc il n'y a jamais de doublon au niveau de la clef.
Il suffirait donc de stocker l'id session dans une nouvelle colonne.
Et on supprimerait en fonction de l'id à la fin de chaque session ?

[Stane]

J'ai une clef qui s'incrémente a chaque ajout de ligne. Donc il n'y a jamais de doublon au niveau de la clef.
Il suffirait donc de stocker l'id session dans une nouvelle colonne.
Et on supprimerait en fonction de l'id à la fin de chaque session ?

OUI
A la fin de session ou apres le traitement, depends de l'appli

OU

faire la méthode de sauvegarde et de l’exploitation des données "synchronized" qui empêchera qu'il y à deux utilisateurs qui font commit ?

[Pwill]

J'ai une clef qui s'incrémente a chaque ajout de ligne. Donc il n'y a jamais de doublon au niveau de la clef.
Il suffirait donc de stocker l'id session dans une nouvelle colonne.
Et on supprimerait en fonction de l'id à la fin de chaque session ?

faire la méthode de sauvegarde et de l’exploitation des données "synchronized" qui empêchera qu'il y à deux utilisateurs qui font commit ?

Tu pourrais détailler un peu ce que tu entends par la svp ?

Il se passerait quoi ?
Plusieurs personnes seraient momentanément en attente et ca peut prendre du temps que l'utilisateur libère l'accès à la table.

[barbu0055]

A ta place je regarderai du coté des verrous.
Voila la page de manuel des verrou pour PostgreSQL :
http://www.postgresql.org/docs/7.2/s...s.html#AEN9066

Il suffit de poser un verrou sur la ligne ou tu travailles, et ca ne bloquera la ligne qu en ecriture et pas en lecture.

[Pwill]

Merci à toi, je vais me renseigner sur les verrous et voir ce que je peux en faire.

[Pwill]

Le chargement de données dans la table va demander du temps selon la connexion... un fichier ferait logiquement mini 17mo de texte brut

X arrive sur le site et charge ses données dans la table. Etant donné le temps nécessaire il est parti faire autre chose, lorsqu'il revient il remplit le formulaire et à la validation un select est effectué sur la table.

Il ne faudrait pas qu'entre temps Y ait fini de charger de nouvelles données dans la table.

Commencer une transaction protégée par un verrou EXCLUSIVE lors de l'insertion des données, terminer la transaction après le select serait une solution ?

[NGY]

Salut,

Je ne vois pas bien pourquoi limiter à une seule opération à la fois.

Comme l'a suggéré Stane je pense que le mieux est de créer une table temporaire dont qui comporte en plus un champ ID_SESSION (ou ID_UTILISATEUR à la rigueur).

X arrive sur le site et charge ses données dans la table. Etant donné le temps nécessaire il est parti faire autre chose, lorsqu'il revient il remplit le formulaire et à la validation un select est effectué sur la table.

Jusque là OK : il charge ses données dans la table en mettant son idSession dans ID_SESSION.

Il ne faudrait pas qu'entre temps Y ait fini de charger de nouvelles données dans la table.

Ben si, maintenant si Y se pointe avant qu'X ait supprimé ses données, c'est pas grave, Y charge ses données en renseignat la colonne avec son propre idSession.

Une fois que X (ou Y) a effectué ses action (select * from tableTempo where ID_SESSION = idSession) sur la table temporaire, il les supprime de la table (delete tableTempo where ID_SESSION=idSession).

Comme ça, X et Y ne se marchent pas sur les piends.

[Pwill]

Effectivement, cette solution de Stane me semble assez simple à implémenter.

Seulement barbu lui aurait fait avec des verrous, ptet c'est moins couteux, seulement je n'ai pas de notions avancées en bd.

[barbu0055]

alors si g bien compris ta solution, tu veut faire une table temporaire ou tout le monde pourra mettre ce qu'il veut dedans.
Donc si chaque personne a 17k lignes à entrer comme le disait Pwill et qu il y a une centaine d'utilisateurs (pqoi pas) ca va faire 1700k ligne dans la table rien que ca.
Pas mal comme solution surtout au niveau au niveau optimisation d'espace.
En plus si mes souvenirs sont bon, un insert dans une table pose un verrou sur la table, donc au niveau optimisation temps, ca se pose la aussi ta proposition.
Mais bon , de mon coté je suis incapable de te dire comme ca qu'elle serai la solution la plus optimale. Ca demande un minimum de temps de reflexion que je n'ai pas. Mais si une idée me vient je te la fait parvenir.
++

[NGY]

En plus si mes souvenirs sont bon, un insert dans une table pose un verrou sur la table, donc au niveau optimisation temps, ca se pose la aussi ta proposition.

??? Excuse-moi de mettre tes souvenirs en doute, mais je vois mal un SGBD digne de ce nom poser un verrou sur toute la table pour un insert !
C'est d'ailleurs la pose de verrous qui n'est pas terrible au niveau perfs.
Sinon, pour le reste, je suis bien d'accord que ma méthode n'optimise pas l'espace disque, mais enfin, charger des fichiers de plusieur Mo en BD, ça va forcément bouffer de la place.

[Pwill]

Hmm bon, il faut savoir que ce site ne devrait pas attirer foule de scientifiques... et que je doute qu'il y ait souvent 2 utilisateurs en simultané à travailler chacun depuis leurs données météos. S'il y a 100 visiteurs pas mois, ca sera déjà pas mal il me semble.

Je me suis planté, en fait le programmme peut tourner avec des données sur une année complète, soit 365 lignes.

Je devrais donc m'orienter vers la solution de l'id_session