felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Auge <raymond.a...@liferay.com>
Subject Re: [Discuss] Resolver 'latch' bundle / sub module
Date Thu, 10 Nov 2016 14:51:47 GMT
We've also implemented a robust, services based DB Schema upgrade and
verification framework.

First off, schema are named (this could be one or more associated tables).

The schema runtime publishes all known schema "versions" once it's ready,
each as a service.

The upgrade services are dependent on particular versions of a named
schema, thus a sequence of upgrades services can operate in succession, or
one upgrade can make a large jump from one schema version to a much later

Of course when an upgrade is in progress the schema is un-published and so
no persistence operations can take place.

Once the upgrade is complete it tells the schema engine which version was
created, and the schema runtime announces the schema version as a service.

The persistence services depend on particular schema versions and so they
cannot provide services without a proper schema.

With this framework we can:
- create schema from scratch
- do live upgrades
- block wrongly deployed versions so they don't screw up the data
- block new versions which don't provide adequate upgrade from the existing
schema to the expected one
- take persistence services out of us while upgrades are happening
- schema may depend on other schema/services
- the upgrade framework will parallelize upgrade operations where the
upgrade graph allows

We're using this framework now for more than 2 years with around 100 schema.

It's awesome to see a newly started system come up from either zero
database or from an older version to latest, performing all upgrades along
the way in a cascade fan out.

- Ray

On Thu, Nov 10, 2016 at 8:56 AM, Jan Willem Janssen <
janwillem.janssen@luminis.eu> wrote:

> Hi,
> > On 10 Nov 2016, at 13:27, davidb@apache.org wrote:
> >
> > In some cases I have a requirement that a bundle should not resolve (or
> > start) when a certain external 'thing' hasn't taken place yet. For
> example
> > maybe you may not want to start a certain bundle until some operations
> have
> > been performed on a database.
> I’m not sure I understand the rationale for making the bundle
> non-resolvable
> when you want to wait for a certain (service?) operation to be complete.
> If you’re talking about database migrations that need to be performed
> before
> the services of your bundle are exposed to the rest of the system, then you
> could also prevent them from being registered until the migration scripts
> are
> finished. For a project of ours, we’ve implemented this pattern for all of
> our database migrations and it works really well. For this, we used a
> custom
> on/off service-dependency (we’re using DM4 for that) for our services that
> we
> could flip once the migration was complete causing DM to actually register
> the services.
> --
> Met vriendelijke groeten | Kind regards
> Jan Willem Janssen | Software Architect
> +31 631 765 814
> My world is something with Amdatu and Apache
> Luminis Technologies
> Churchillplein 1
> 7314 BZ  Apeldoorn
> +31 88 586 46 00
> https://www.luminis.eu
> KvK (CoC) 09 16 28 93
> BTW (VAT) NL8170.94.441.B.01

*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message