4 ms·

> there's even a version of the JVM with code reloading. Yes, because of Java's extensible classloading mechanism, all you have to do is drop an war/ear to the

> there's even a version of the JVM with code reloading. Yes, because of Java's extensible classloading mechanism, all you have to do is drop an war/ear to the 'deploy' folder of your application server. New files are deployed, rewritten files are redeployed and deleted files are undeployed.

phamilton 13y ago
Is there a mechanism to migrate existing data to the new code?
- simula67 13y ago
  If you have external state stored in say a database, I think you have to control your deployments to migrate the schema before the model objects can be deployed.
  - phamilton 13y ago
    So no. One of the beauties of Erlang's hot code loading is the ability to migrate internal application state. An example: I'm storing a lookup table going from key to value as a tuple {key, value}. With a change going out, I'm going to start doing {key, {value, other-value}}. In Erlang there's an easy pattern in place to do that. Just provide a function that goes from {key, value} to {key, {value, sensible-default}} and as part of the code reloading process that function will be run before the new code starts executing.
    - simula67 13y ago
      You may have misunderstood. A file can have multiple, say 'deployment units'. You can have a 'migrate deployment unit' which depend on the 'model deployment unit' which forces the app server to deploy the migrate unit first. You can have code there that migrates the tables and fill with default values before your model entities become available for use. From your comment this seems to be the same as what Erlang does for your example, unless you are claiming that Erlang's implementation is superior which could be the true, since I have never written any non-trivial programs in it.
      - bitwalker 13y ago
        I think the difference here is that the migration of internal state happens the moment the module is swapped out in memory. Erlang doesn't have mutable state, so state is instead passed around within a module. When a fix needs to be deployed, the two versions (old and new) run simultaneously, any new processes immediately run the new code, old processes call a `code_change` function which takes the current state within that process, performs any transformations required for the new code, and then the old module code is swapped out for the new. That's not at all a perfect explanation of the process, but it's more or less useful enough to describe the difference between the two platforms.
cmsd2 13y ago
sure, any existing connections continue to be serviced by the old code, and new connections are picked up by the new code. if you need more elaborate lifecycle management of components as they are upgraded, then maybe OSGI could do that. erlang's approach really appeals to me though -- not only does the code get upgraded, but it's in cooperation with its message loop so you don't miss a step, and you also get a callback to migrate your actor state.

phamilton 13y ago

Is there a mechanism to migrate existing data to the new code?

simula67 13y ago
If you have external state stored in say a database, I think you have to control your deployments to migrate the schema before the model objects can be deployed.
- phamilton 13y ago
  So no. One of the beauties of Erlang's hot code loading is the ability to migrate internal application state. An example: I'm storing a lookup table going from key to value as a tuple {key, value}. With a change going out, I'm going to start doing {key, {value, other-value}}. In Erlang there's an easy pattern in place to do that. Just provide a function that goes from {key, value} to {key, {value, sensible-default}} and as part of the code reloading process that function will be run before the new code starts executing.
  - simula67 13y ago
    You may have misunderstood. A file can have multiple, say 'deployment units'. You can have a 'migrate deployment unit' which depend on the 'model deployment unit' which forces the app server to deploy the migrate unit first. You can have code there that migrates the tables and fill with default values before your model entities become available for use. From your comment this seems to be the same as what Erlang does for your example, unless you are claiming that Erlang's implementation is superior which could be the true, since I have never written any non-trivial programs in it.
    - bitwalker 13y ago
      I think the difference here is that the migration of internal state happens the moment the module is swapped out in memory. Erlang doesn't have mutable state, so state is instead passed around within a module. When a fix needs to be deployed, the two versions (old and new) run simultaneously, any new processes immediately run the new code, old processes call a `code_change` function which takes the current state within that process, performs any transformations required for the new code, and then the old module code is swapped out for the new. That's not at all a perfect explanation of the process, but it's more or less useful enough to describe the difference between the two platforms.

cmsd2 13y ago

sure, any existing connections continue to be serviced by the old code, and new connections are picked up by the new code. if you need more elaborate lifecycle management of components as they are upgraded, then maybe OSGI could do that. erlang's approach really appeals to me though -- not only does the code get upgraded, but it's in cooperation with its message loop so you don't miss a step, and you also get a callback to migrate your actor state.