IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Spring Java Discussion :

[Transaction] Transactions longues et annulation


Sujet :

Spring Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Février 2004
    Messages
    23
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 23
    Par défaut [Transaction] Transactions longues et annulation
    Bonjour,

    Alors voilà, j'ai besoin de pourvoir ouvrir une transaction longue sur un ensemble d'objets pour modification (enchainement d'écrans et traitement parfois longs).

    Je pensais passer pour ça par le gestion des transactions de spring (avec verrou pessimiste sur la base via hibernate) et un scope conversation via Spring Web Flow.

    D'où ma première question : Est-ce que cette solution est envisageable et viable ?

    Deuxième point, l'administrateur doit pouvoir annuler les transactions lancées par l'utilisateur. Et la je ne vois pas comment le lister et encore moins comment les annuler.

    Quelqu'un aurait-il une idée de la manière dont je pourrais réaliser ça ?

    Merci d'avance.
    Julien

  2. #2
    Membre chevronné Avatar de djsnipe
    Inscrit en
    Mai 2008
    Messages
    440
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 440
    Par défaut
    Une transaction longue ne me semble pas être la meilleur idée. Pourquoi ne pas garder les données en mémoire avant de faire une persistance unique ? Ca évite notamment les timeout de transaction inévitables.
    Pour lister les transactions en cours et pouvoir les annuler ça me semble particulièrement difficile si on parle de transactions BDD. Par contre, on peut toujours construire un système où l'application simule des "opérations métier" dont on garde une trace dans des tables particulières.
    Après c'est prise de tête de devoir avoir des tables qui indiquent les modifications apportées par utilisateur. Et ca devient difficilement annulable si une autre "transaction" à modifié une donnée après celle que l'on souhaite annuler. Ou alors traquer les modifs dans des tables dédiées, et n'impacter les tables réelles que lorsque l'admin ne peut plus (ou n'a plus le droit) annuler. Mais alors chaque donnée lue depuis la base doit faire l'objet d'un traitement avec l'historique des modifs qui s'appliquent à elle... grosse prise de tête !

    Si qq'un à une meilleur idée, je serai curieux de la connaitre .

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Février 2004
    Messages
    23
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 23
    Par défaut
    Merci djsnipe,

    Tu confirmes ce que je pensais je m'embarque dans quelque chose de bien galère ...

    Le plus simple va être de creuser le besoin alors et de voir comment on peut faire autrement ...

    Julien

    PS : Si quelqu'un à d'autres idées je suis preneur quand même.

Discussions similaires

  1. [Data] [Transaction] @Transactional - le rollback ne fonctionne pas
    Par romaintaz dans le forum Spring
    Réponses: 6
    Dernier message: 11/10/2009, 17h23
  2. [Data] [Transaction] @transactional et multiple transaction manager
    Par trungsi dans le forum Spring
    Réponses: 1
    Dernier message: 08/02/2009, 20h51
  3. Réponses: 2
    Dernier message: 08/03/2007, 12h46
  4. [SQLITE][TRANSACTION] transaction répartie entre threads
    Par nannous dans le forum Autres éditeurs
    Réponses: 2
    Dernier message: 16/11/2006, 10h24
  5. Réponses: 7
    Dernier message: 29/11/2005, 11h07

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo