Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-20829

Add mechanism to reliably migrate persistent timers to between TimerService implementations

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • 37.0.0.Final
    • Clustering, EJB
    • None
    • ---
    • ---

      Applications using persistent timers via the database or file-based timer-stores wishing to use the new Infinispan-based TimerService currently have no way to migrate existing applications with existing persistent timers.
      The RFE proposes to add the ability to define a migration timer-store to the EJB subsystem.
      When specified, a deploying EJB (i.e. before PostConstruct) will interrogate the migration timer store, recreating timers in the new TimerService and removing any successfully migrated entries. For shared timer stores (i.e. database), care must be taken that migration actions are performed atomically and with appropriate isolation, since other servers may be actively using this store.
      The initial scope will include only those migration paths whose source is a timer-store, i.e.:

      • file -> Infinispan
      • database -> Infinispan
      • file -> database
      • database -> file
        Migration from Infinispan to file or database store is optional scope, since the Infinispan-based TimerService is not a timer-store resource (i.e. it does not implement the TimerPersistence SPI), it can be considered a separate piece of work.
        This feature may be backported to EAP 8.0/8.1, using a system property in place of management model changes.

              Unassigned Unassigned
              pferraro@redhat.com Paul Ferraro
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: