Issues when updating running apps?
 

Hello all,

I have a very basic question I hope someone can help me with.

I'm not sure on how to package an application so that updating it while
it's running won't cause any problems. For instance, I'm packaging a
quite typical java app that has a swing GUI and stores its data in a
database. In the event of an update requiring modifications to the
database schema I had thought of including these in the %pre or %post
sections, but I assume this could lead to the app breaking to pieces if
the old version is running when the changes meant for the newer version
are made. A similar problem could occur if I update some jar and the
running app happens to load some classes from it that won't work
properly with the older version. Am I making any sense with this?


How can I get around these issues? are there other I should look out for
that I'm not considering?


I'd highly appreciate any advice/tips/links you could give me.

Regards.

Adrián.


_______________________________________________
Rpm-list mailing list
Rpm-list@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list

Issues when updating running apps?
 

Hi everyone,

I apologize for insisting on this matter, but so far I haven't been able
to find info on this anywhere. I've looked at tomcat's and openoffice's
spec files as examples of packaged java apps, but it doesn't seem they
take any sort of precaution when updating. Is it really not an issue if
the app happens to be running at the time?


As for updating a database schema accessed by our app, I suppose we
could add that logic to the app itself and have it check before it
starts whether it should modify the database, but I find adding scripts
in the RPM much easier and I'd prefer any problems with the
modifications to come up the moment the update is applied and not
whenever the app is next started.


I'd really appreciate any comments you could give me on this, whether
they are direct answers, indirect tips on how I could find this info, or
kind advice to go RTFM (as long as you tell me which FM in particular
that would be :) )


I thank you all already for your time.

Regards.

Adrián.

Adrián Márques escribió:

Hello all,

I have a very basic question I hope someone can help me with.

I'm not sure on how to package an application so that updating it
while it's running won't cause any problems. For instance, I'm
packaging a quite typical java app that has a swing GUI and stores its
data in a database. In the event of an update requiring modifications
to the database schema I had thought of including these in the %pre or
%post sections, but I assume this could lead to the app breaking to
pieces if the old version is running when the changes meant for the
newer version are made. A similar problem could occur if I update some
jar and the running app happens to load some classes from it that
won't work properly with the older version. Am I making any sense with
this?


How can I get around these issues? are there other I should look out
for that I'm not considering?


I'd highly appreciate any advice/tips/links you could give me.

Regards.

Adrián.





_______________________________________________
Rpm-list mailing list
Rpm-list@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list

Issues when updating running apps?
 

> I apologize for insisting on this matter, but so far I haven't been able
> to find info on this anywhere. I've looked at tomcat's and openoffice's
> spec files as examples of packaged java apps, but it doesn't seem they
> take any sort of precaution when updating. Is it really not an issue if
> the app happens to be running at the time?

In my experience I don't know that I've found a single web app that seems
to be overly concerned with this process inside the rpms. We have some
internal java web apps, and I believe they just have "turn off x and y
services" listed in the update docs we distribute.

> As for updating a database schema accessed by our app, I suppose we
> could add that logic to the app itself and have it check before it
> starts whether it should modify the database, but I find adding scripts
> in the RPM much easier and I'd prefer any problems with the
> modifications to come up the moment the update is applied and not
> whenever the app is next started.

Once again, I haven't seen many that addresses this issue. Part of the
problem of including this inside the RPM is the db authentication method.
I believe most apps I've seen require you to install the RPM, and then run
either a schema import or update script. I've thought about this on my own
though and have decided that I like the concept of my application being
aware of its own schema, and managing the changes to the db itself (i
realize that this can in and of itself be a bit of a nightmare, but then so
is making schema changes via package managers). Remember, I haven't tried
implementing it.

> I'd really appreciate any comments you could give me on this, whether
> they are direct answers, indirect tips on how I could find this info, or
> kind advice to go RTFM (as long as you tell me which FM in particular
> that would be :) )

I was avoiding commenting on this because I didn't have any solid answers
for you, but at this point I guess opinion and conjecture is enough since
no one else has commented.

enjoy

-greg

_______________________________________________
Rpm-list mailing list
Rpm-list@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list

Issues when updating running apps?
 

Thanks for your answer Greg. You were right; even opinion and conjecture
are helpful.


Fellow packager Tim Born also kindly shared his experience directly with
me (thanks Tim!), and with his permission I'm posting his response to
the list in order to share it with everyone else.


Is there anyone else that could provide any input on this?
As an extra comment, the app in question is not a daemon, it's
user-interactive, so stopping it in the %pre section prior to the update
is not an option for me.


Thanks.

Tim's email:

Hello Adrian -

I'm surprised the RPM for the application being updated does not stop &
restart the service daemon(s) as part of the update.

That was how I was taught to do things.

I suppose it's possible there are apps out there that can ride over
having their files being changed out from under them.
Not many of mine can. So in the %pre we check for an update and stop
the app, then in the %post we again check to see if this is an update &
restart the app.


Works well for us.

best
-tim

Greg_Swift@aotx.uscourts.gov escribió:

I apologize for insisting on this matter, but so far I haven't been able
to find info on this anywhere. I've looked at tomcat's and openoffice's
spec files as examples of packaged java apps, but it doesn't seem they
take any sort of precaution when updating. Is it really not an issue if
the app happens to be running at the time?



In my experience I don't know that I've found a single web app that seems
to be overly concerned with this process inside the rpms. We have some
internal java web apps, and I believe they just have "turn off x and y
services" listed in the update docs we distribute.



As for updating a database schema accessed by our app, I suppose we
could add that logic to the app itself and have it check before it
starts whether it should modify the database, but I find adding scripts
in the RPM much easier and I'd prefer any problems with the
modifications to come up the moment the update is applied and not
whenever the app is next started.



Once again, I haven't seen many that addresses this issue. Part of the
problem of including this inside the RPM is the db authentication method.
I believe most apps I've seen require you to install the RPM, and then run
either a schema import or update script. I've thought about this on my own
though and have decided that I like the concept of my application being
aware of its own schema, and managing the changes to the db itself (i
realize that this can in and of itself be a bit of a nightmare, but then so
is making schema changes via package managers). Remember, I haven't tried
implementing it.



I'd really appreciate any comments you could give me on this, whether
they are direct answers, indirect tips on how I could find this info, or
kind advice to go RTFM (as long as you tell me which FM in particular
that would be :) )



I was avoiding commenting on this because I didn't have any solid answers
for you, but at this point I guess opinion and conjecture is enough since
no one else has commented.

enjoy

-greg

_______________________________________________
Rpm-list mailing list
Rpm-list@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list



_______________________________________________
Rpm-list mailing list
Rpm-list@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list

Issues when updating running apps?
 

Hello there,

I tried my luck with this question at linuxquestions.org and got a
couple of answers already.


In case you want to take a look at them:

http://www.linuxquestions.org/questions/linux-general-1/how-to-upgrade-running-apps-preferably-through-rpm-673813/

Cheers.

Adrián.

Adrián Márques escribió:
Thanks for your answer Greg. You were right; even opinion and
conjecture are helpful.


Fellow packager Tim Born also kindly shared his experience directly
with me (thanks Tim!), and with his permission I'm posting his
response to the list in order to share it with everyone else.


Is there anyone else that could provide any input on this?
As an extra comment, the app in question is not a daemon, it's
user-interactive, so stopping it in the %pre section prior to the
update is not an option for me.


Thanks.

Tim's email:

Hello Adrian -

I'm surprised the RPM for the application being updated does not stop
& restart the service daemon(s) as part of the update.

That was how I was taught to do things.

I suppose it's possible there are apps out there that can ride over
having their files being changed out from under them.
Not many of mine can. So in the %pre we check for an update and stop
the app, then in the %post we again check to see if this is an update
& restart the app.


Works well for us.

best
-tim

Greg_Swift@aotx.uscourts.gov escribió:
I apologize for insisting on this matter, but so far I haven't been
able

to find info on this anywhere. I've looked at tomcat's and openoffice's
spec files as examples of packaged java apps, but it doesn't seem they
take any sort of precaution when updating. Is it really not an issue if
the app happens to be running at the time?



In my experience I don't know that I've found a single web app that
seems

to be overly concerned with this process inside the rpms. We have some
internal java web apps, and I believe they just have "turn off x and y
services" listed in the update docs we distribute.



As for updating a database schema accessed by our app, I suppose we
could add that logic to the app itself and have it check before it
starts whether it should modify the database, but I find adding scripts
in the RPM much easier and I'd prefer any problems with the
modifications to come up the moment the update is applied and not
whenever the app is next started.



Once again, I haven't seen many that addresses this issue. Part of the
problem of including this inside the RPM is the db authentication
method.
I believe most apps I've seen require you to install the RPM, and
then run
either a schema import or update script. I've thought about this on
my own

though and have decided that I like the concept of my application being
aware of its own schema, and managing the changes to the db itself (i
realize that this can in and of itself be a bit of a nightmare, but
then so
is making schema changes via package managers). Remember, I haven't
tried

implementing it.



I'd really appreciate any comments you could give me on this, whether
they are direct answers, indirect tips on how I could find this
info, or

kind advice to go RTFM (as long as you tell me which FM in particular
that would be :) )



I was avoiding commenting on this because I didn't have any solid
answers
for you, but at this point I guess opinion and conjecture is enough
since

no one else has commented.

enjoy

-greg

_______________________________________________
Rpm-list mailing list
Rpm-list@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list



_______________________________________________
Rpm-list mailing list
Rpm-list@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list


_______________________________________________
Rpm-list mailing list
Rpm-list@redhat.com
https://www.redhat.com/mailman/listinfo/rpm-list