Skip to main content

Deployment: if it goes bad, what state is GlassFish in?

1 reply [Last post]
ljnelson
Offline
Joined: 2003-08-04
Points: 0

I've played around off and on for...wow, years now :-| with Liquibase (
http://www.liquibase.org) and its support for running database updates at
ServletContext initialization time.

Head over to the website for more details, but in brief Liquibase manages
DDL commands against your database. It ships with an optional
ServletContextListener so that you can run these idempotent updates (well
they're idempotent if they've been run before :-)) every time your
application is deployed (every time the servlet context is initialized).
There are obviously pros and cons to this, but it's at any rate
interesting.

Sometimes your database update scripts are um shall we say syntax
challenged. I of course have never ever written such a syntax challenged
database upgrade scripts. Ahem.

Anyhow, at that point Liquibase fails, and the servlet context listener
fails, and some kind of RuntimeException is thrown--and the deployment
obviously is screwed up. Er, I mean, I have this friend to whom this sort
of thing happens. Sometimes.

But I've (he's) noticed that this leaves GlassFish in some kind of
indeterminate state. I'm writing this from memories of this occurring in
the past, but I seem to recall that the security/policy generation stuff
has partially completed at this point and isn't cleaned up or something of
that nature.

Is it supposed to be the case that if a deployment bombs out during
ServletContext initialization that GlassFish should be fully cleaned up
afterwards, or is this such a crazy thing in the lifecycle of the container
that there's not really an opportunity to clean up?

Best,
Laird

--
http://about.me/lairdnelson

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mvatkina
Offline
Joined: 2005-04-04
Points: 0

Laird Nelson wrote:
> I've played around off and on for...wow, years now :-| with Liquibase
> (http://www.liquibase.org) and its support for running database
> updates at ServletContext initialization time.
>
> Head over to the website for more details, but in brief Liquibase
> manages DDL commands against your database. It ships with an optional
> ServletContextListener so that you can run these idempotent updates
> (well they're idempotent if they've been run before :-)) every time
> your application is deployed (every time the servlet context is
> initialized). There are obviously pros and cons to this, but it's at
> any rate interesting.
>
> Sometimes your database update scripts are um shall we say syntax
> challenged. I of course have never ever written such a syntax
> challenged database upgrade scripts. Ahem.
>
> Anyhow, at that point Liquibase fails, and the servlet context
> listener fails, and some kind of RuntimeException is thrown--and the
> deployment obviously is screwed up. Er, I mean, I have this friend to
> whom this sort of thing happens. Sometimes.
>
> But I've (he's) noticed that this leaves GlassFish in some kind of
> indeterminate state. I'm writing this from memories of this occurring
> in the past, but I seem to recall that the security/policy generation
> stuff has partially completed at this point and isn't cleaned up or
> something of that nature.
>
> Is it supposed to be the case that if a deployment bombs out during
> ServletContext initialization that GlassFish should be fully cleaned
> up afterwards, or is this such a crazy thing in the lifecycle of the
> container that there's not really an opportunity to clean up?

Deployment is calling a cleanup callback so everything should be cleaned
up on a failed deploy, but we do encounter bugs sometimes ;)

-marina
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>