Releasing Java Client & Database Schema Changes

chatterbox

Hi All,

I'm investigating options regarding how to improve my current release process for releasing Java client that may sometimes preforms database schema changes as part of the release.

My current process is

• Copy in new java home
• Run Java class that will upgrade the database .. this may take hours:mad:

The main problem with the above is the downtime while the database objects get created.

In the majority of cases I could potentially get most of the DB work done upfront and then the release process would be simple software upgrade\copy.

So at the moment I'm leaning towards creating a standalone release utility that doesn't required the new software to be in please to run the Java Class to upgrade the DB.

Can anyone give me some of their thoughts and experiences on this topic. The main objective to minimize downtime when DB changes are involved.

Thanks in advance.

Procasinator

Why does it take hours to upgrade the database? Sometimes there is methods to make these changes quicker, so it might be worth investigating if you can speed this up. Can you give an example of what kind of changes take that long, and what RDBMS you are using?

If you modify the DB before releasing the new build, you would need to make sure the current program can run with the changes meant for the new build. Often this isn't too difficult, but you could need to deploy an intermediate shim to manually handle incompatibilities.

chatterbox

Thanks for the reply Procasinator ...

Its a Oracle DB, that contains tables with 100-400 million rows in some of them, so some index \ materialized view creation commands can take 1+ hours across a RAC environment, some release may create 2 or 3 indexes.

I was hoping to create these type of objects up front so the release did the min amount of work possible.

The versions control wont be an issue as I'm only going to create standalone objects upfront that will not harm the current version.

I have a couple of a approaches in my head, but I was I'm just wondering how other people have addresses these kind of release issues.

croo

Run Java class that will upgrade the database .. this may take hours

I would imagine that using the DB tools run locally would be much quicker at updating the DB than a java class/app accessing the db via jdbc.

ChRoMe

croo wrote: »

I would imagine that using the DB tools run locally would be much quicker at updating the DB than a java class/app accessing the db via jdbc.

Why would you think that, ultimately they are just both issuing SQL to the server?

chatterbox

I'm pretty sure its the same execution time, regardless of if its executed directly on DB Vs JDBC call

I'm using
oracleUtils.execute("CREATE INDEX NEW_IDX ON TEST_TABLE (TEST_ID,TEST_NAME)");

croo

if the migration were so straight forward then agreed. But with no details I assumed the worst.
If I take an extreme example as pointer to what I was thinking.
In our application we have an order which has one or more lines,
The model change adds a new column "total" and the new code includes a new method to calculate this by adding the sum of the lines. Someone *might* add the new column then loop through all orders,instantiating them (thereby loading it and all its lines) and calling the new method to update the new total field. Then persistenting the updated order (and lines) back and moving to the next order.

Running on the same machine this would be much slower than sql -running as a client machine would cause all the orders and lines to be passed to the client for processing.

A simple and extreme example, but don't believe people haven't done it!

ps. webstart can be useful to deploy clients and ensure they are on the same version as the server. The initial load is a little slower as it first compares the installed client to the version the server is deploying and if needs be updates the client. But it works and makes client deployment much easier. After saying that I would think most people today (writing java) are writing web based solutions so there is zero client deployment which is even easier!