7 Replies Latest reply on Nov 5, 2012 9:14 AM by shawkins

    Questions about importing VDBs

    markaddleman

      The VDB import feature (aka VDB reuse: https://docs.jboss.org/author/display/teiid81final/VDB+Reuse) hold a lot of promise for us, I think.  I've mentioned elsewhere that we separately ship modules to enable various functionality in our base product.  As far as Teiid is concerned, a module is a VDB-like-thing, perhaps some translators and data sources.  When the module gets deployed, I'd like to import it into our base VDB with as little disruption to existing VDB clients as possible.  So, a few questions:

      1. I suppose we hook into JBoss deployment facility to know when a module is deployed?
      2. The expectation is to redpeloy our base VDB when a new module is deployed?  I suppose we could use a custom metadata repository to programmatically control the base VDB?
      3. Is the new base VDB considered a new version so we can drain live transactions from the old VDB and then undeploy it?
        • 1. Re: Questions about importing VDBs
          rareddy
          1. I suppose we hook into JBoss deployment facility to know when a module is deployed?

          Yes, You can register for VBDLifecycleListner to get events about when the VDB is deployed.

           

           

          1. The expectation is to redpeloy our base VDB when a new module is deployed?  I suppose we could use a custom metadata repository to programmatically control the base VDB?

          Yes, however for your base VDB you still would need a market xml file that represents a VDB, which would contain those imported VDB definitions.

           

           

          1. Is the new base VDB considered a new version so we can drain live transactions from the old VDB and then undeploy it?

          It is considered new version, however the version number is not updated automatically. It would replace the current VDB, unless you define the base VDB with different version number. The connections will be terminated against the old vdb.

          • 2. Re: Questions about importing VDBs
            shawkins

            > Yes, You can register for VBDLifecycleListner to get events about when the VDB is deployed.

             

            There's a JIRA for that: https://issues.jboss.org/browse/TEIID-2182

             

            > Yes, however for your base VDB you still would need a market xml file that represents a VDB, which would contain those imported VDB definitions.

             

            When an imported vdb is redeployed, any importing vdb is automatically redeployed as well.

            • 3. Re: Questions about importing VDBs
              markaddleman

              > Yes, however for your base VDB you still would need a market xml file that represents a VDB, which would contain those imported VDB definitions.

               

              When an imported vdb is redeployed, any importing vdb is automatically redeployed as well.

              Not sure I understand.  Must our base VDB be a physical XML file or can it be constructed programmatically?  If physical, suppose a module VDB is added or removed, our code could be informed via VDBLifecycleListener, then adjust the base VDB appropriately and redeploy?

              • 4. Re: Questions about importing VDBs
                shawkins

                > Not sure I understand.  Must our base VDB be a physical XML file or can it be constructed programmatically?  If physical, suppose a module VDB is added or removed, our code could be informed via VDBLifecycleListener, then adjust the base VDB appropriately and redeploy?

                 

                I'm just trying to clearify the deployment affects.  We have imported vdbs and importing vdbs.  How those vdbs are created does not matter.  All that matters is that the importing vdb.xml files contain the appropriate imports.  When an importing vdb is deployed, it will not be loaded until all of its imported vdbs are available.  It will automatically finish loading once all of the imported vdbs are available.  If an imported vdb is redeployed (same version number), then any importing vdbs will redeploy themselves automatically as well to pick up the changes.

                 

                So you only have to manually modify/redeploy the importing (base vdb) when you are adding a new or removing an imported vdb.  Modifying an existing imported vdb via a redeploy is automatically handled.

                 

                And just to make sure, until TEIID-2182 is worked there isn't a public way of using vdb listeners.

                • 5. Re: Questions about importing VDBs
                  markaddleman

                  Thanks Steve.  I think I got it.  I'm trying to get a leg up on planning for our next release (we won't be ready to start development for a couple more months).  With some good luck, TEIID-2182 will be completed by then.

                  • 6. Re: Questions about importing VDBs
                    markaddleman

                    Our application will connect to the importing VDB.  When an imported VDB is redeployed, I'd like a way to either safely drain in-flight transactions or find out which connections have been terminated so any work can be automatically re-established against the new VDB.  By re-established I mean, retry data modifying transactions and restart continuous queries.

                     

                    I see a few possible solutions:

                    1. Abruptly terminate connections by throwing a well-specified exception (TeiidSQLVDBRedeployedException ?)
                    2. Enhance the VDBLifecycleListener to allow listeners to pause the redeployment
                    3. Increase the version number of the importing VDB on every redeploy
                    4. Enhance the VDBLifecycleListener to allow a listener to modify the version number of the importing VDB (this is my favorite option)

                     

                    Thoughts?

                    • 7. Re: Questions about importing VDBs
                      shawkins

                      Mark,

                       

                      1) With the current logic you would see an invalid session exception, but would not know that it was due to a redeploy.  It may be possible to make this more specific.

                       

                      2/3) MetaMatrix used to function in a similar way in that operations to an active vdb required no sessions before they were allowed to complete and redeployment issued a new version number.  In general there was confusion as to what vdb version meant in the old days.  There were effectively 2 versions - deployment version (which was managed by the server) and design time version - that were not correlated.  For Teiid and the AS deployment mechanism it didn't make sense to continue with those approaches.  So what you are trying to do more logically fits into the new way of doing thing with 4) - in that you have a new refinement of the imported vdb rather than simply overwriting and expecting a automatic server revision.

                       

                      4) That would require the hook to effectively copy the current importing deployment, increment and deploy.  You would probably want a way to mark the old importing version as obsolete and eligible for auto-cleanup when there are no active sessions (which is somewhat similar to the approach that was used previously for 2).

                       

                      Steve