This content has been marked as final. Show 6 replies
It will only cause a stale state if you re-deploy the same revision. If you deploy the new composite as a new revision then the old instances won't be stale. The new revision becomes the default and all new instances are created there unless someone is specifically calling the older revision endpoint. You can also retire the old revision to not allow any new instances to be created but allow the existing ones to finish running.
This is not my problem. This is something know and familiar.
I'm talking about the right methodology, and the correct way to build and maintain the process.
If I have 30 composite, and I need each time to deploy new revision, I will end up with 300 composite under my SOA server.
When using few bpel components in 1 composite - for each component change, I will modify the composite revision?
Is this the way to work with in Oracle SOA Suite?
It really depends on your requirements. It depends if the processes are short lived or long running as well as how you want to handle rollbacks and other things.
We use new revisions since we have long running processes that we can't have go stale every time we deploy a new revision. Also if we need to backout our newly deployed changes its just an undeploy of the new revision, no need to redeploy the old code since it is still there. Cleaning out the old revisions is just maintenance that needs to be done, and would depend again on your specific case. They don't need to stay deployed forever.
Also if these are short running processes and there is no problem with instances going stale you can just deploy the same revision, although that does make tracking releases harder.