7 Replies Latest reply on Nov 13, 2006 10:01 AM by huberth

    Singleton persistence archive, datasource?

    huberth

      This may seem a bit odd, but I'm trying to keep my persistence archive and datasource definition in the hasingleton directory so that they only get deployed on the master. I've successfully placed all services that use an entity manager there as well, so no services should require these things on anything but the master.

      The reason I'd like to do this is that the database (TimesTen in-memory db) can only be used on the master given our db replication configuration (TimesTen's active/standby pair) and, for the sake of managing the replication, I need to guarantee that there are no connections to the standby db.

      Simply placing my persistence jar file and my app-ds.xml into the deploy-hasingleton directory yields a 'NameNotFoundException: app-ds not bound' while trying to deploy the persistence unit. The incomplete deployment listing at the end of startup indicates that the persistence unit failed to deploy due to a dependency on the corresponding datasource's ManagedConnectionFactory.

      I suspect bad timing, as the line following the exception suggests that the datasource is bound immediately afterward (admittedly, I may be jumping to conclusions on this). I attempted to add a jboss.depends property to my persistence.xml (naming the offending service), but that didn't seem to change anything. I've also tried moving just the app-ds.xml file back to the 'deploy' directory to no avail.

      This all works if all of these files are in the deploy directory with, of course, the exception that I have the undesirable db connections on the non-master node.

      Is there some way to accomplish this? Or is this whole idea doomed to fail for this or other reasons? Are there other ways of forcing all db connections off of the non-master?

      Any help would be greatly appreciated.

      Hubert

        • 1. Re: Singleton persistence archive, datasource?
          huberth

          Forgot to mention...

          I'm using 4.0.4.GA, with EJB3.

          • 2. Re: Singleton persistence archive, datasource?
            brian.stansberry

            What did the "depends" element you added to the persistence archjve look like?

            Also, does packaging the persistence archive and the -ds.xml together in a sar help?

            I'm thinking this is due with the fact that the deploy-hasingleton folder is deployed as a deployment itself, all of the items contained within deploy-hasingleton are then deployed as sub-deployments of the parent deployment. A side effect of this is normal deployment ordering rules do not apply.

            Another thing to look at for a workaround is using the BarrierController discussed on http://wiki.jboss.org/wiki/Wiki.jsp?page=HASingletonDeployer.

            • 3. Re: Singleton persistence archive, datasource?
              huberth

              I copied the object name from the log output :



              I just tried packaging in a sar but I get the same result.

              I have actually been playing with a barrier mbean as well to find a work-around for this issue. What I did is move all of my par's, dependent ear's, and the datasource definition into a different (i.e. made up by me) deploy directory. Then when my mbean is 'started' I call on the main deployer to deploy that directory, and vice-versa when 'stopped'. This all seems to go cleanly. Do you see any issues with such an approach?

              Honestly, I thought this approach would have led to the same problems, but I tried it as a first step... the next step would have been to stage the deploy and undeploy in separate directories, in dependency order.

              • 4. Re: Singleton persistence archive, datasource?
                huberth

                I don't know what happeend to my property definition in that post. I checked the 'Disable HTML in this post' box... did I misunderstand the meaning of that?

                Anyway, here it is, minus the angle-brackets just to be safe:

                property name="jboss.depends.1" value="jboss.jca:name=tpapps-ds,service=ManagedConnectionFactory"

                • 5. Re: Singleton persistence archive, datasource?
                  huberth

                  While we're on barriers, the documentation seems to suggest that a singleton barrier mbean will have it's 'create' method called at system startup, deferring the 'start' method call until the node becomes the master.

                  I'm not seeing my create method get called until the node becomes master either.

                  Which way is it supposed to work?

                  • 6. Re: Singleton persistence archive, datasource?
                    brian.stansberry

                    Responding to various points...

                    1) I don't know what "Disable HTML" does. But I do know you have to use the Code button above the input box to get XML to appear correctly :)

                    2) What does the descriptor for your service that deploys from another directory look like? Sounds very much like the deployer for deploy-hasingleton (which is the first mbean in the deploy/deploy-hasingleton-service.xml file). So I agree - it's odd it worked differently

                    3) For a dependency, try jboss.jca:name=tpapps-ds,service=DataSourceBinding

                    That's the service that actually binds your datasource in JNDI.

                    4) My reading of the docs and of the org.jboss.system.BarrierController code leads me to expect your create() should be called after deploy, with start() deferred until the node becomes master. Not sure why you're not seeing that.

                    • 7. Re: Singleton persistence archive, datasource?
                      huberth

                      First of all, thanks alot for the prompt replies!

                      And in response to:

                      1) Thanks, I'll make sure I do that.

                      2) The jboss-service.xml is just a stub (empty server tag), as we rely exclusively on annotations. Here are the annotations, though:

                      @Management(DatabaseManager.class)
                      @Service(objectName = "my.domain:service=DatabaseManager")
                      @RemoteBinding(jndiBinding = DatabaseManager.JNDI_NAME)
                      @Depends("jboss.ha:service=HASingletonDeployer,type=Barrier")
                      


                      The create method, for now, just logs that it is being called.

                      The start method finds the MainDeployer (MBeanServerLocator.locateJBoss, MBeanServerInvocationHandler.newProxyInstance, objectName="jboss.system:service=MainDeployer", etc), and calls deploy on it, passing the directory's url (file:/..../server/default/deploy-db/).

                      The stop method is the same as start, except, of course, it calls undeploy.

                      3) Changing the dependency works. Everything seems to come up without incident. Given your comment in 2) about it being odd that it worked differently, I presume that even if I go the barrier-controller route, it'd be wise to keep this dependency, yes?

                      I'd like to go with the barrier-controller as it gives me more precise control over the timing of the replication management tasks relative to shutting down or starting up the db services.

                      4) It definitely does not call create until the subsequent switch-over. Here's the stack trace at the point at which my create method is called:

                      Thread "AsynchKeyChangeHandler Thread"@4,007 in group "jboss" status: RUNNING
                      create():49, my.domain.databasemanager.DatabaseManagerMBean
                      invoke0():-1, sun.reflect.NativeMethodAccessorImpl
                      invoke():39, sun.reflect.NativeMethodAccessorImpl
                      invoke():25, sun.reflect.DelegatingMethodAccessorImpl
                      invoke():585, java.lang.reflect.Method
                      invokeNext():109, org.jboss.aop.joinpoint.MethodInvocation
                      invoke():54, org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor
                      invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation
                      invoke():47, org.jboss.ejb3.AllowedOperationsInterceptor
                      invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation
                      invokeInOurTx():79, org.jboss.aspects.tx.TxPolicy
                      invoke():192, org.jboss.aspects.tx.TxInterceptor$Required
                      invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation
                      invoke():76, org.jboss.aspects.tx.TxPropagationInterceptor
                      invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation
                      invoke():78, org.jboss.aspects.security.AuthenticationInterceptor
                      invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation
                      invoke():47, org.jboss.ejb3.ENCPropagationInterceptor
                      invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation
                      invoke():106, org.jboss.ejb3.asynchronous.AsynchronousInterceptor
                      invokeNext():98, org.jboss.aop.joinpoint.MethodInvocation
                      localInvoke():181, org.jboss.ejb3.service.ServiceContainer
                      localInvoke():142, org.jboss.ejb3.service.ServiceContainer
                      invoke():168, org.jboss.ejb3.service.ServiceMBeanDelegate
                      invoke():164, org.jboss.mx.server.RawDynamicInvoker
                      invoke():659, org.jboss.mx.server.MBeanServerImpl
                      invoke():995, org.jboss.system.ServiceController$ServiceProxy
                      create():-1, $Proxy0
                      create():330, org.jboss.system.ServiceController
                      invoke0():-1, sun.reflect.NativeMethodAccessorImpl
                      invoke():39, sun.reflect.NativeMethodAccessorImpl
                      invoke():25, sun.reflect.DelegatingMethodAccessorImpl
                      invoke():585, java.lang.reflect.Method
                      invoke():155, org.jboss.mx.interceptor.ReflectedDispatcher
                      dispatch():94, org.jboss.mx.server.Invocation
                      invoke():86, org.jboss.mx.server.Invocation
                      invoke():264, org.jboss.mx.server.AbstractMBeanInvoker
                      invoke():659, org.jboss.mx.server.MBeanServerImpl
                      invoke():210, org.jboss.mx.util.MBeanProxyExt
                      create():-1, $Proxy128
                      installMBean():109, org.jboss.ejb3.JmxKernelAbstraction
                      registerManagementInterface():352, org.jboss.ejb3.service.ServiceContainer
                      start():92, org.jboss.ejb3.service.ServiceContainer
                      invoke0():-1, sun.reflect.NativeMethodAccessorImpl
                      invoke():39, sun.reflect.NativeMethodAccessorImpl
                      invoke():25, sun.reflect.DelegatingMethodAccessorImpl
                      invoke():585, java.lang.reflect.Method
                      startService():99, org.jboss.ejb3.ServiceDelegateWrapper
                      jbossInternalStart():289, org.jboss.system.ServiceMBeanSupport
                      jbossInternalLifecycle():245, org.jboss.system.ServiceMBeanSupport
                      invoke():-1, sun.reflect.GeneratedMethodAccessor2
                      invoke():25, sun.reflect.DelegatingMethodAccessorImpl
                      invoke():585, java.lang.reflect.Method
                      invoke():155, org.jboss.mx.interceptor.ReflectedDispatcher
                      dispatch():94, org.jboss.mx.server.Invocation
                      invoke():86, org.jboss.mx.server.Invocation
                      invoke():264, org.jboss.mx.server.AbstractMBeanInvoker
                      invoke():659, org.jboss.mx.server.MBeanServerImpl
                      invoke():978, org.jboss.system.ServiceController$ServiceProxy
                      start():-1, $Proxy0
                      start():417, org.jboss.system.ServiceController
                      start():435, org.jboss.system.ServiceController
                      invoke():-1, sun.reflect.GeneratedMethodAccessor9
                      invoke():25, sun.reflect.DelegatingMethodAccessorImpl
                      invoke():585, java.lang.reflect.Method
                      invoke():155, org.jboss.mx.interceptor.ReflectedDispatcher
                      dispatch():94, org.jboss.mx.server.Invocation
                      invoke():86, org.jboss.mx.server.Invocation
                      invoke():264, org.jboss.mx.server.AbstractMBeanInvoker
                      invoke():659, org.jboss.mx.server.MBeanServerImpl
                      start():194, org.jboss.system.ServiceMBeanSupport
                      startBarrier():334, org.jboss.system.BarrierController
                      handleNotification2():313, org.jboss.system.BarrierController
                      handleNotification():403, org.jboss.system.ListenerServiceMBeanSupport
                      invoke():-1, sun.reflect.GeneratedMethodAccessor3
                      invoke():25, sun.reflect.DelegatingMethodAccessorImpl
                      invoke():585, java.lang.reflect.Method
                      invoke():153, org.jboss.mx.notification.NotificationListenerProxy
                      handleNotification():-1, $Proxy101
                      handleNotification():127, org.jboss.mx.util.JBossNotificationBroadcasterSupport
                      sendNotification():110, org.jboss.mx.util.JBossNotificationBroadcasterSupport
                      sendNotificationToLocalListeners():354, org.jboss.ha.jmx.HAServiceMBeanSupport
                      sendLocalNotification():213, org.jboss.ha.singleton.HASingletonSupport
                      makeThisNodeMaster():200, org.jboss.ha.singleton.HASingletonSupport
                      partitionTopologyChanged():133, org.jboss.ha.singleton.HASingletonSupport
                      replicantsChanged():243, org.jboss.ha.jmx.HAServiceMBeanSupport$1
                      notifyKeyListeners():844, org.jboss.ha.framework.server.DistributedReplicantManagerImpl
                      processEvent():386, org.jboss.ha.framework.server.DistributedReplicantManagerImpl
                      run():107, org.jboss.ha.framework.server.AsynchEventHandler
                      run():595, java.lang.Thread
                      


                      Getting the create method called at system startup would be nice so I don't have to create yet another MBean just to know that the system started up.