10 Replies Latest reply on May 27, 2003 6:46 AM by riki1512

    Some questions

    riki1512

      Hi,

      I'm wondering that i can't find this question anywhere: How can I automatically instantiate one Bean when the Server is started or the .jar file is deployed ? Maybe i can't find it because it makes no sense ?

      I've got to manage some socket-connections and I'm using the beans because every connection then is automatically managed in a thread. I've got a Connection-Pool, and the beans only work as a facade to ask the pool for one connection. That works nice, but I have a static constructor in the pool to open the socket-connections i need. The first-time the Connection-Pool is loaded by the VM, and that goes with the first client sending a Message using my beans, the sockets are opened. That is not really clean. What do I have to do that one Bean is instantiated at the server-start or after deploying ? Or better that a static-constructor of a class is started at the Server-start - or after deploying.

      On the outgoing side, i have 4 or more connections, so i have a ConnectionPool, a static Hashtable where i manage the Sockets.

      But on the ingoing side, there must be only one connection, one socket. (Connection to legacy system). It sounds simple, but how can i get sure that that Connection is opened only once ? I can't use a static constructor there because I need a 'normal' constructor with parameters. I can't build a Pool around with a static constructor again because there is only one connection and so that would by a poor elusion...
      It really sounds easy but i can't solve it. I could add the incoming connection as a static field in the Pool, beside the Hashtable. But I can't start the inStream.read-method because this method blocks the thread. I have to start it from another bean to use another thread (and I don't want to programme a thread because they all say that it's so nice using the beans because you don't have to worry about threads...). But how can I start the inStream.read - method only once over a bean ? Maybe at the start of the server - somehow automatically ? But makes it really sense that one bean would then exist as long as i read Messages over the InputStream from the Socket ?

      Maybe there is a very simple solution or it even is'nt really a problem but i'ts friday, I slept only 5 hours and my brain is full - or empty...

      Any answers, please ?

        • 1. Re: Some questions

          EJBs are not intended for this kind of work.
          They are themselves pooled.

          You should write it as an MBean or if you
          need integration with transactions/security
          it should be a jca adaptor (which is also more
          portable).

          Regards,
          Adrian

          • 2. Re: Some questions
            riki1512

            Thank you for your answer,

            I know that ejb's are pooled - of course, but i read that you should'nt integrate socket-connections in a bean, rather you should use for example your own instance-pool and the beans only as a facade that use the connections from the pool. For example because socket-connections are not seriazable and you have not control how many objects their exactly will be craeted or kept in the pool...
            Why not to use ejb's ? I've realized n outgoing connections, each in its own thread. On the other side, we have some Entity-beans to store what goes out , what in...

            Did'nt we use the advantages of ejb's ? Not to worry about Threads or the Database-querys and Connections ? Later easy to add more components ? We have a Web-frontend, so we can realize it by servlets and jsp. We have a nice separation in Presentation, logic and persistence - with our own connection-pool. Why do you think ejb's are not the right solution for us ?
            My only problem is how can i realize my ingoing connection - one Socket instantiated and connected only once, without a gantry-class with a static constructor around, because it's ApplicationServers thing when to instantiate, when to destroy or when to passivate a bean.
            I could do it with a stateful session-bean as a facade, started only once and kept alive as long as the server lives, but I dont't know if I can do that or it makes sense...
            If I would use a MessageDriven-Bean I would need a seperate Java-programm to realize my server which informs the JMS-server, i thing that would be more complicated.
            Please answer, your opinion as a expert is very important for me (when I read your first answer, there was a picture from a programmer in UK, adrian - are you the one ?)

            • 3. Re: Some questions
              riki1512

              Thank you for your answer,

              I know that ejb's are pooled - of course, but i read that you should'nt integrate socket-connections in a bean, rather you should use for example your own instance-pool and the beans only as a facade that use the connections from the pool. For example because socket-connections are not seriazable and you have not control how many objects their exactly will be craeted or kept in the pool...
              Why not to use ejb's ? I've realized n outgoing connections, each in its own thread. On the other side, we have some Entity-beans to store what goes out , what in...

              Did'nt we use the advantages of ejb's ? Not to worry about Threads or the Database-querys and Connections ? Later easy to add more components ? We have a Web-frontend, so we can realize it by servlets and jsp. We have a nice separation in Presentation, logic and persistence - with our own connection-pool. Why do you think ejb's are not the right solution for us ?
              My only problem is how can i realize my ingoing connection - one Socket instantiated and connected only once, without a gantry-class with a static constructor around, because it's ApplicationServers thing when to instantiate, when to destroy or when to passivate a bean.
              I could do it with a stateful session-bean as a facade, started only once and kept alive as long as the server lives, but I dont't know if I can do that or it makes sense...
              If I would use a MessageDriven-Bean I would need a seperate Java-programm to realize my server which informs the JMS-server, i thing that would be more complicated.
              Please answer, your opinion as a expert is very important for me (when I read your first answer, there was a picture from a programmer in UK, adrian - are you the one ?)

              • 4. Re: Some questions
                riki1512

                Thank you for your answer,

                I know that ejb's are pooled - of course, but i read that you should'nt integrate socket-connections in a bean, rather you should use for example your own instance-pool and the beans only as a facade that use the connections from the pool. For example because socket-connections are not seriazable and you have not control how many objects their exactly will be craeted or kept in the pool...
                Why not to use ejb's ? I've realized n outgoing connections, each in its own thread. On the other side, we have some Entity-beans to store what goes out , what in...

                Did'nt we use the advantages of ejb's ? Not to worry about Threads or the Database-querys and Connections ? Later easy to add more components ? We have a Web-frontend, so we can realize it by servlets and jsp. We have a nice separation in Presentation, logic and persistence - with our own connection-pool. Why do you think ejb's are not the right solution for us ?
                My only problem is how can i realize my ingoing connection - one Socket instantiated and connected only once, without a gantry-class with a static constructor around, because it's ApplicationServers thing when to instantiate, when to destroy or when to passivate a bean.
                I could do it with a stateful session-bean as a facade, started only once and kept alive as long as the server lives, but I dont't know if I can do that or it makes sense...
                If I would use a MessageDriven-Bean I would need a seperate Java-programm to realize my server which informs the JMS-server, i thing that would be more complicated.
                Please answer, your opinion as a expert is very important for me (when I read your first answer, there was a picture from a programmer in UK, adrian - are you the one ?)

                • 5. Re: Some questions
                  riki1512

                  Thank you for your answer,

                  I know that ejb's are pooled - of course, but i read that you should'nt integrate socket-connections in a bean, rather you should use for example your own instance-pool and the beans only as a facade that use the connections from the pool. For example because socket-connections are not seriazable and you have not control how many objects their exactly will be craeted or kept in the pool...
                  Why not to use ejb's ? I've realized n outgoing connections, each in its own thread. On the other side, we have some Entity-beans to store what goes out , what in...

                  Did'nt we use the advantages of ejb's ? Not to worry about Threads or the Database-querys and Connections ? Later easy to add more components ? We have a Web-frontend, so we can realize it by servlets and jsp. We have a nice separation in Presentation, logic and persistence - with our own connection-pool. Why do you think ejb's are not the right solution for us ?
                  My only problem is how can i realize my ingoing connection - one Socket instantiated and connected only once, without a gantry-class with a static constructor around, because it's ApplicationServers thing when to instantiate, when to destroy or when to passivate a bean.
                  I could do it with a stateful session-bean as a facade, started only once and kept alive as long as the server lives, but I dont't know if I can do that or it makes sense...
                  If I would use a MessageDriven-Bean I would need a seperate Java-programm to realize my server which informs the JMS-server, i thing that would be more complicated.
                  Please answer, your opinion as a expert is very important for me (when I read your first answer, there was a picture from a programmer in UK, adrian - are you the one ?)

                  • 6. Re: Some questions
                    riki1512

                    Thank you for your answer,

                    I know that ejb's are pooled - of course, but i read that you should'nt integrate socket-connections in a bean, rather you should use for example your own instance-pool and the beans only as a facade that use the connections from the pool. For example because socket-connections are not seriazable and you have not control how many objects their exactly will be craeted or kept in the pool...
                    Why not to use ejb's ? I've realized n outgoing connections, each in its own thread. On the other side, we have some Entity-beans to store what goes out , what in...

                    Did'nt we use the advantages of ejb's ? Not to worry about Threads or the Database-querys and Connections ? Later easy to add more components ? We have a Web-frontend, so we can realize it by servlets and jsp. We have a nice separation in Presentation, logic and persistence - with our own connection-pool. Why do you think ejb's are not the right solution for us ?
                    My only problem is how can i realize my ingoing connection - one Socket instantiated and connected only once, without a gantry-class with a static constructor around, because it's ApplicationServers thing when to instantiate, when to destroy or when to passivate a bean.
                    I could do it with a stateful session-bean as a facade, started only once and kept alive as long as the server lives, but I dont't know if I can do that or it makes sense...
                    If I would use a MessageDriven-Bean I would need a seperate Java-programm to realize my server which informs the JMS-server, i thing that would be more complicated.
                    Please answer, your opinion as a expert is very important for me (when I read your first answer, there was a picture from a programmer in UK, adrian - are you the one ?)

                    • 7. Re: Some questions
                      riki1512

                      Thank you for your answer,

                      I know that ejb's are pooled - of course, but i read that you should'nt integrate socket-connections in a bean, rather you should use for example your own instance-pool and the beans only as a facade that use the connections from the pool. For example because socket-connections are not seriazable and you have not control how many objects their exactly will be craeted or kept in the pool...
                      Why not to use ejb's ? I've realized n outgoing connections, each in its own thread. On the other side, we have some Entity-beans to store what goes out , what in...

                      Did'nt we use the advantages of ejb's ? Not to worry about Threads or the Database-querys and Connections ? Later easy to add more components ? We have a Web-frontend, so we can realize it by servlets and jsp. We have a nice separation in Presentation, logic and persistence - with our own connection-pool. Why do you think ejb's are not the right solution for us ?
                      My only problem is how can i realize my ingoing connection - one Socket instantiated and connected only once, without a gantry-class with a static constructor around, because it's ApplicationServers thing when to instantiate, when to destroy or when to passivate a bean.
                      I could do it with a stateful session-bean as a facade, started only once and kept alive as long as the server lives, but I dont't know if I can do that or it makes sense...
                      If I would use a MessageDriven-Bean I would need a seperate Java-programm to realize my server which informs the JMS-server, i thing that would be more complicated.
                      Please answer, your opinion as a expert is very important for me (when I read your first answer, there was a picture from a programmer in UK, adrian - are you the one ?)

                      • 8. Re: Some questions
                        riki1512

                        Sorry for the x replies, but I tried it several times and the replies have not been visible for me - even after 2 hours...

                        • 9. Re: Some questions

                          Socket processing is I/O which is potentially
                          a blocking operation.

                          EJB are designed as components under
                          the control of an application server.
                          The app server manages resources (however
                          naively).

                          If you want to do resource management you
                          are part of the the app server,
                          for jboss this means MBeans.

                          If you want a clean interface with j2ee security
                          or transaction then a jca adaptor is a better option.

                          Regards,
                          Adrian

                          • 10. Re: Some questions
                            riki1512

                            Ok,

                            thank you for your posts. I'll look what i can find about MBeans and jca...

                            ciao
                            Riki