Re: hot redeployment - how to preserve session state?
Hi Aaron, We preserve session state through hot and cold deploys with no problem, unless you explicitly change the objects involved in keeping the session state, or any object that is stored in the context. However, it is not impossible to modify these objects while preserving your state, as long as you know how to handle serialisation issues. If you are careful with the classes you put in sessions and the context ( make them serializable and take into account the possible evolution of classes ) then you will minimize your problems. Have a look at the "Object Serialization" part of the Java SDK Documentation to learn more about that. BTW: The attribute to get persistence to work in Orion is not development=true but persistence-path="../temp/persistence.ser". So your global-web-application.xml should look something like... ... I hope it helps, D. Aaron Tavistock wrote: > I'm not currently doing hot-deploy, but I've always wonder how it could > posibly work given that a serialized class might have the underlying base > class changed during hot-deploy (e.g. the classic 'run instance' is > different than a 'new instance' problem that java throws a > ClassCastException from). Its also theoretically problematic (I'm not sure > if instanceof or reflection will work properly). > > Since this is a very low-level issue (e.g. Java simply doesn't have the > facilities to really handle this), how does hot-deply work? The only > reliable strategy would appear to be to preserver primatives (since they > don't change), maybe preserve 'well-defined' objects (java.util.* is > unlikely to change), and discard all the rest. > > Any thoughts? > > AT > > -Original Message- > From: Peter Beck [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 29, 2002 7:41 AM > To: Orion-Interest > Subject: hot redeployment - how to preserve session state? > > > After a forced redeployment of an application on Orion 1.5.3 by touching > application.xml > my session state seemst to be completely lost. > > I have set development=true in my global-web-application.xml, and the > switch is present in the orion-web.xml in the application- deployment > directory. > The variables I try to serialize implement the Serializable interface. > Some of them are simple JavaBeans, others just Strings. > > For testing I use a JSP which prints the variables in the session. > Before the redeployment everything is there. > and when a user is logged in, request.getRemoteUser() gives me the > correct user name. > After the redeployment session.toString() still gives me the same ID as > before, but all variables in the session are gone. > Even request.getRemoteUser() == null. > > What am I missing? > > Peter
MQSeries as JMS provider?
Hi: Has anyone have any sucess integrating MQSeries as the JMS provider for the orion server? Thanks keith
long sessions
I have kind of a general app server question:
I have a servlet that puts a user object into session
-
HttpSession session = req.getSession(true);
session.setAttribute("user", user);
-
We use this object to check if a visitor has logged into the web site or not
My boss has asked me to increase the timeout of this session to 8 hours !!!
Apart from the obvious security issue, I was wondering about the load on
the server. Is holding too many session at once a common cause of server
failure ?
I can't really give details about the number of users, but assume there
will be a few hundred at any one time.
The hardware specs of the app server are about mid range.
thanks
Re: What is a Dirty Connection (using -Djdbc.debug=true)
Yes, sounds like Orion isn't closing the Statements and ResultSets that it uses for CMP, instead it is just closing the Connection. If that is the case, either an update in the Oracle JDBC driver or an update with Orion would fix the bug. Let's hope one of the two comes out soon, because how it is now is very bad. -Pat - Original Message - From: "Jeff Hubbach" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Tuesday, January 29, 2002 2:10 PM Subject: Re: What is a Dirty Connection (using -Djdbc.debug=true) > Patrick, > > It helped in that noone else responded, and it points to the fact that something, either a statement or result set, isn't getting closed (if container-managed connections are dealt with the same as user-managed connections, which I'm assuming is true). > > I agree with you that he's talking about BMP, but the underlying connection stuff should be the same (except for the fact that the container is handling it instead of us, in which case you'd think it would be sure to close everything, but it doesn't look like it is). > > Some suggestions have been to move from CMP to BMP, but in my opinion that's taking a step backwards. It sounds like there's a problem in the container's handling of connections, but we have yet to hear anything from anyone with any code-level knowledge of Orion. Magnus, is this an issue? and if so, is it going to be fixed in Orion 1.5.4, and if so, when will we see it? > > Jeff. > > On Tue, 29 Jan 2002 11:28:18 -0800 > "Patrick Lightbody" <[EMAIL PROTECTED]> wrote: > > > I don't see how this helps with your question at all. You were asking about > > CMP, and he is talking about BMP. I too have the problems you are > > encoutering with CMP and stale connections being left over. I'd love to hear > > of solutions to this problem. > > > > -Pat > > > > - Original Message - > > From: "Jeff Hubbach" <[EMAIL PROTECTED]> > > To: "Orion-Interest" <[EMAIL PROTECTED]> > > Sent: Tuesday, January 29, 2002 8:25 AM > > Subject: Fw: What is a Dirty Connection (using -Djdbc.debug=true) > > > > > > > I'm forwarding this on to the list as it was very helpful with regard to > > my question, just incase anyone else has the same questions. Thanks, Avi. > > > > > > Jeff. > > > > > > Begin forwarded message: > > > > > > Date: Tue, 29 Jan 2002 08:50:25 +0200 > > > From: Avi Abrami <[EMAIL PROTECTED]> > > > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > > Subject: What is a Dirty Connection (using -Djdbc.debug=true) > > > > > > > > > Hi Jeff, > > > I'm not subscribed to the Orion-Interest mailing list, > > > but I monitor it through the OrionServer website. I > > > hope you don't mind that I am answering you via a direct > > > eMail. > > > > > > This is what I know about "dirty connections". > > > (Note that you may already know some of what I am about > > > to tell you, I hope that's OK with you.) > > > > > > Orion "wraps" the JDBC driver classes. It seems to me, > > > from debug messages displayed by the server, (but I haven't > > > verified this yet) that Orion uses different wrapper > > > classes depending on whether the server is running in > > > debug mode or regular mode. I have had my application > > > crash when running in debug mode, but work properly when > > > working in regular (as in non-debug) mode. > > > > > > As far as I can ascertain, a "dirty connection" is one > > > that has an associated "open" Statement or ResultSet or > > > PreparedStatement, etc. object. I have found that the > > > only way to properly "close" a Connection is to first > > > close the ResultSet object, then the Statement object > > > and finally the Connection object. Note that I am only > > > working with the Oracle JDBC driver that comes with > > > OC4J (and my version is 1.0.2.2 -- on SUN Solaris 2.7) > > > > > > Further, the following methods from the JDBC API do not > > > work correctly (when using Orion's JDBC wrapper classes): > > > > > > ResultSet.getStatement() > > > > > > Statement.getConnection() > > > > > > These methods execute normally -- they don't throw > > > exceptions at runtime and they compile without an problems. > > > However, it seems like they do nothing! > > > > > > Basically a "dirty connection" means you have database > > > resources (like Statement objects or ResultSet objects) > > > still lying around -- which need to be disposed of (or > > > "closed"). This is sort of like a memory leak, because > > > eventually the Oracle database will exhaust all its > > > resources and throw SQLExceptions in your application. > > > > > > The only way I found to properly "close" these database > > > resource associated objects (Connection, Statement, > > > ResultSet, etc) was to hold on to the references after > > > I created the objects and only use those references to > > > "close" those objects. So if, for example, you open a > > > Connection in one method and that method returns a > > > ResultSet to a calling method, the calling method will > > >
RE: Container leaving Dirty Connection in CMP with container-managed transactions
You could try using your own wrappers on the JDBC classes ala this article http://www.onjava.com/lpt/a/onjava/2001/12/05/optimization.html Then, you can see exactly what Orion is calling. At least that helps track the bug down a bit. Actually, maybe you could use this method to force Oracle to clean itself up better? That is, to enforce the contract of the Connection.close() method (as pointed out in Avi's email that you forwarded to the list). Actually, if what he says is true, maybe all us Oracle users could use some wrappers like that! :-) Cheers geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeff Hubbach Sent: Wednesday, January 30, 2002 3:44 AM To: Orion-Interest Subject: Container leaving Dirty Connection in CMP with container-managed transactions If an exception is thrown in a CMP entity bean with container-managed transactions, a Dirty Connection is left behind that is never cleaned up (or at least in 15 minutes). We've set inactivity-timeout in the data-sources and tweaked with all the transaction settings, all to no avail. Is anyone experiencing this? It does this with Oracle (running Oracle's driver as well as Merant's), PostgreSQL, and SQL Server (running Merant's driver). The biggest issue is that the dirty connection in Oracle and SQL Server is holding a lock to the row that caused the exception, preventing any further access, actually deadlocking the server (in PostgreSQL, further updates to that row go through just fine). Or at least this is what we _think_ is happening, as there's no better explanation that we've found. Jeff.
Re: What is a Dirty Connection (using -Djdbc.debug=true)
Patrick, It helped in that noone else responded, and it points to the fact that something, either a statement or result set, isn't getting closed (if container-managed connections are dealt with the same as user-managed connections, which I'm assuming is true). I agree with you that he's talking about BMP, but the underlying connection stuff should be the same (except for the fact that the container is handling it instead of us, in which case you'd think it would be sure to close everything, but it doesn't look like it is). Some suggestions have been to move from CMP to BMP, but in my opinion that's taking a step backwards. It sounds like there's a problem in the container's handling of connections, but we have yet to hear anything from anyone with any code-level knowledge of Orion. Magnus, is this an issue? and if so, is it going to be fixed in Orion 1.5.4, and if so, when will we see it? Jeff. On Tue, 29 Jan 2002 11:28:18 -0800 "Patrick Lightbody" <[EMAIL PROTECTED]> wrote: > I don't see how this helps with your question at all. You were asking about > CMP, and he is talking about BMP. I too have the problems you are > encoutering with CMP and stale connections being left over. I'd love to hear > of solutions to this problem. > > -Pat > > - Original Message - > From: "Jeff Hubbach" <[EMAIL PROTECTED]> > To: "Orion-Interest" <[EMAIL PROTECTED]> > Sent: Tuesday, January 29, 2002 8:25 AM > Subject: Fw: What is a Dirty Connection (using -Djdbc.debug=true) > > > > I'm forwarding this on to the list as it was very helpful with regard to > my question, just incase anyone else has the same questions. Thanks, Avi. > > > > Jeff. > > > > Begin forwarded message: > > > > Date: Tue, 29 Jan 2002 08:50:25 +0200 > > From: Avi Abrami <[EMAIL PROTECTED]> > > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > Subject: What is a Dirty Connection (using -Djdbc.debug=true) > > > > > > Hi Jeff, > > I'm not subscribed to the Orion-Interest mailing list, > > but I monitor it through the OrionServer website. I > > hope you don't mind that I am answering you via a direct > > eMail. > > > > This is what I know about "dirty connections". > > (Note that you may already know some of what I am about > > to tell you, I hope that's OK with you.) > > > > Orion "wraps" the JDBC driver classes. It seems to me, > > from debug messages displayed by the server, (but I haven't > > verified this yet) that Orion uses different wrapper > > classes depending on whether the server is running in > > debug mode or regular mode. I have had my application > > crash when running in debug mode, but work properly when > > working in regular (as in non-debug) mode. > > > > As far as I can ascertain, a "dirty connection" is one > > that has an associated "open" Statement or ResultSet or > > PreparedStatement, etc. object. I have found that the > > only way to properly "close" a Connection is to first > > close the ResultSet object, then the Statement object > > and finally the Connection object. Note that I am only > > working with the Oracle JDBC driver that comes with > > OC4J (and my version is 1.0.2.2 -- on SUN Solaris 2.7) > > > > Further, the following methods from the JDBC API do not > > work correctly (when using Orion's JDBC wrapper classes): > > > > ResultSet.getStatement() > > > > Statement.getConnection() > > > > These methods execute normally -- they don't throw > > exceptions at runtime and they compile without an problems. > > However, it seems like they do nothing! > > > > Basically a "dirty connection" means you have database > > resources (like Statement objects or ResultSet objects) > > still lying around -- which need to be disposed of (or > > "closed"). This is sort of like a memory leak, because > > eventually the Oracle database will exhaust all its > > resources and throw SQLExceptions in your application. > > > > The only way I found to properly "close" these database > > resource associated objects (Connection, Statement, > > ResultSet, etc) was to hold on to the references after > > I created the objects and only use those references to > > "close" those objects. So if, for example, you open a > > Connection in one method and that method returns a > > ResultSet to a calling method, the calling method will > > not be able to close the Connection unless you also > > pass a reference to the Connection to the calling method. > > > > Also note, that the Oracle JDBC driver also does not > > correctly implement the Connection.close() method. > > According to the API documentation, closing a Connection > > is supposed to also close any associated Statements, > > ResultSets, etc. However, the Oracle JDBC driver does > > not. You need to explicitly close the ResultSet, then > > the Statement, then the Connection. > > > > So in summary, I will answer your questions individually > > now with a short answer, below: > > > > Q:What is a Dirty Connection (when using -Djdbc.debug=true)? > > A:A connection with unclosed r
RE: hot redeployment - how to preserve session state?
I'm not currently doing hot-deploy, but I've always wonder how it could posibly work given that a serialized class might have the underlying base class changed during hot-deploy (e.g. the classic 'run instance' is different than a 'new instance' problem that java throws a ClassCastException from). Its also theoretically problematic (I'm not sure if instanceof or reflection will work properly). Since this is a very low-level issue (e.g. Java simply doesn't have the facilities to really handle this), how does hot-deply work? The only reliable strategy would appear to be to preserver primatives (since they don't change), maybe preserve 'well-defined' objects (java.util.* is unlikely to change), and discard all the rest. Any thoughts? AT -Original Message- From: Peter Beck [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 29, 2002 7:41 AM To: Orion-Interest Subject: hot redeployment - how to preserve session state? After a forced redeployment of an application on Orion 1.5.3 by touching application.xml my session state seemst to be completely lost. I have set development=true in my global-web-application.xml, and the switch is present in the orion-web.xml in the application- deployment directory. The variables I try to serialize implement the Serializable interface. Some of them are simple JavaBeans, others just Strings. For testing I use a JSP which prints the variables in the session. Before the redeployment everything is there. and when a user is logged in, request.getRemoteUser() gives me the correct user name. After the redeployment session.toString() still gives me the same ID as before, but all variables in the session are gone. Even request.getRemoteUser() == null. What am I missing? Peter
RE: Servlet reload problem
Title: RE: Servlet reload problem Are u using code that is calling another servlet? Or is this servlet being called from another one. Cause if the servlet is being called by another one you'd have to move both over both Joseph Faisal Nusairat, Sr. Applications Developer WorldCom tel: 614-723-4232 pager: 888-452-0399 textmsg: [EMAIL PROTECTED] -Original Message- From: Jeff Hubbach [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 29, 2002 1:14 PM To: Orion-Interest Subject: Re: Servlet reload problem touching web.xml works for me, the container reloads the new servlet classes. Jeff. On Tue, 29 Jan 2002 17:00:20 +0100 Paul van Beukering <[EMAIL PROTECTED]> wrote: > restart orion > > -Original Message- > From: Tommi Penttilä [mailto:[EMAIL PROTECTED]] > Sent: dinsdag 29 januari 2002 12:20 > To: Orion-Interest > Subject: Servlet reload problem > > > > My servlet-classes won't reload. After I recompile changed servlet and > http-GET > it via orion's (1.5.3) web-interface, orionconsole reports that Servlet was > initialized, but I get the same result on browser than before compiling. > > I did put orion-web-app/@development=true on the web-app-config, but that > doesn't help. How do I unload old servlet-classes from memory? > > Is there anything like Tomcat's context/@reloadable -attribute in Orion? > It's > extremely annoying to reboot orion every time a servlet class changes. > > Or maybe I'm just missing something obvious? Any pointers greatly > appreciated. > > > > > -- Jeff Hubbach Internet Developer Sun Certified Web Component Developer New Media Division ITQ Lata, L.L.C. 303-745-4763 x3114
Re: What is a Dirty Connection (using -Djdbc.debug=true)
I don't see how this helps with your question at all. You were asking about CMP, and he is talking about BMP. I too have the problems you are encoutering with CMP and stale connections being left over. I'd love to hear of solutions to this problem. -Pat - Original Message - From: "Jeff Hubbach" <[EMAIL PROTECTED]> To: "Orion-Interest" <[EMAIL PROTECTED]> Sent: Tuesday, January 29, 2002 8:25 AM Subject: Fw: What is a Dirty Connection (using -Djdbc.debug=true) > I'm forwarding this on to the list as it was very helpful with regard to my question, just incase anyone else has the same questions. Thanks, Avi. > > Jeff. > > Begin forwarded message: > > Date: Tue, 29 Jan 2002 08:50:25 +0200 > From: Avi Abrami <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: What is a Dirty Connection (using -Djdbc.debug=true) > > > Hi Jeff, > I'm not subscribed to the Orion-Interest mailing list, > but I monitor it through the OrionServer website. I > hope you don't mind that I am answering you via a direct > eMail. > > This is what I know about "dirty connections". > (Note that you may already know some of what I am about > to tell you, I hope that's OK with you.) > > Orion "wraps" the JDBC driver classes. It seems to me, > from debug messages displayed by the server, (but I haven't > verified this yet) that Orion uses different wrapper > classes depending on whether the server is running in > debug mode or regular mode. I have had my application > crash when running in debug mode, but work properly when > working in regular (as in non-debug) mode. > > As far as I can ascertain, a "dirty connection" is one > that has an associated "open" Statement or ResultSet or > PreparedStatement, etc. object. I have found that the > only way to properly "close" a Connection is to first > close the ResultSet object, then the Statement object > and finally the Connection object. Note that I am only > working with the Oracle JDBC driver that comes with > OC4J (and my version is 1.0.2.2 -- on SUN Solaris 2.7) > > Further, the following methods from the JDBC API do not > work correctly (when using Orion's JDBC wrapper classes): > > ResultSet.getStatement() > > Statement.getConnection() > > These methods execute normally -- they don't throw > exceptions at runtime and they compile without an problems. > However, it seems like they do nothing! > > Basically a "dirty connection" means you have database > resources (like Statement objects or ResultSet objects) > still lying around -- which need to be disposed of (or > "closed"). This is sort of like a memory leak, because > eventually the Oracle database will exhaust all its > resources and throw SQLExceptions in your application. > > The only way I found to properly "close" these database > resource associated objects (Connection, Statement, > ResultSet, etc) was to hold on to the references after > I created the objects and only use those references to > "close" those objects. So if, for example, you open a > Connection in one method and that method returns a > ResultSet to a calling method, the calling method will > not be able to close the Connection unless you also > pass a reference to the Connection to the calling method. > > Also note, that the Oracle JDBC driver also does not > correctly implement the Connection.close() method. > According to the API documentation, closing a Connection > is supposed to also close any associated Statements, > ResultSets, etc. However, the Oracle JDBC driver does > not. You need to explicitly close the ResultSet, then > the Statement, then the Connection. > > So in summary, I will answer your questions individually > now with a short answer, below: > > Q:What is a Dirty Connection (when using -Djdbc.debug=true)? > A:A connection with unclosed resources lying around. > > Q:What causes it? > A:Not explicitly closing the resources. > > Q:What repercussions does it have? > A:It can crash the database server. > > Q:Is a Dirty Connection a bad thing? > A:Yes. > > Q:What can we do to avoid it (if anything)? > A:Explicitly close all resources -- ResultSets, > Statements, etc. > > Q:Are there any settings that control when and if > they are cleaned up? > A:If you are using pooled connections, perhaps the > "inactivity-timeout" attribute in the "data-sources.xml" > file can help -- I don't know for sure. > > Q:Are they cleaned up at all? > A:As far as I can tell, no. > > A very long post -- I hope you don't mind, and I hope > it can help you. > > Good Luck, > Avi. > > > > -- > Jeff Hubbach > Internet Developer > Sun Certified Web Component Developer > New Media Division > ITQ Lata, L.L.C. > 303-745-4763 x3114
Re: Application Client & JMS
Hi Jochen ,
The MessageMonitor class you have written , is it a servlet?
r u using Orion's JMS?
thanks,
manoj.
Jochen Kressin wrote:
>Hi,
>
>i have some problems writing an application client that uses JMS. I have
>created a SessionBean which publishes messages and a MDB which receives
>the messages. This works fine. I now want to write a client application
>that can participate in messaging.
>
>The client connects to the server without problems, but messages
>published by the client seem to go nowhere. The MDB does not receive
>anything. Also, the client does not receive any messages sent by the
>SessionBean.
>
>The directory structure of the client app is:
>client
> +--- MessageMonitor.class
> +--- META-INF
> +---application-client.xml
> +---orion-application-client.xml
>
>The application-client.xml:
>
>...
>
>jms/TopicConnectionFactory
>javax.jms.TopicConnectionFactory
>Container
>
>
>jms/BenelogNewOrder
>javax.jms.Topic
>Container
>
>
>where "BenelogNewOrder" is the name of the Topic I would like to
>subscribe to.
>
>The client looks up the Topic using something like:
>lookup("java:comp/env/jms/BenelogNewOrder");
>
>Please give me some hint what i am doing wrong. Also, any informations
>where to find more about app-clients & Orion is appreciated. Neither
>orion nor atlassian seem to have tutorials on this topic.
>
>Thanks in advance!
>
>Jochen
>
Re: Servlet reload problem
touching web.xml works for me, the container reloads the new servlet classes. Jeff. On Tue, 29 Jan 2002 17:00:20 +0100 Paul van Beukering <[EMAIL PROTECTED]> wrote: > restart orion > > -Original Message- > From: Tommi Penttilä [mailto:[EMAIL PROTECTED]] > Sent: dinsdag 29 januari 2002 12:20 > To: Orion-Interest > Subject: Servlet reload problem > > > > My servlet-classes won't reload. After I recompile changed servlet and > http-GET > it via orion's (1.5.3) web-interface, orionconsole reports that Servlet was > initialized, but I get the same result on browser than before compiling. > > I did put orion-web-app/@development=true on the web-app-config, but that > doesn't help. How do I unload old servlet-classes from memory? > > Is there anything like Tomcat's context/@reloadable -attribute in Orion? > It's > extremely annoying to reboot orion every time a servlet class changes. > > Or maybe I'm just missing something obvious? Any pointers greatly > appreciated. > > > > > -- Jeff Hubbach Internet Developer Sun Certified Web Component Developer New Media Division ITQ Lata, L.L.C. 303-745-4763 x3114
Container leaving Dirty Connection in CMP with container-managed transactions
If an exception is thrown in a CMP entity bean with container-managed transactions, a Dirty Connection is left behind that is never cleaned up (or at least in 15 minutes). We've set inactivity-timeout in the data-sources and tweaked with all the transaction settings, all to no avail. Is anyone experiencing this? It does this with Oracle (running Oracle's driver as well as Merant's), PostgreSQL, and SQL Server (running Merant's driver). The biggest issue is that the dirty connection in Oracle and SQL Server is holding a lock to the row that caused the exception, preventing any further access, actually deadlocking the server (in PostgreSQL, further updates to that row go through just fine). Or at least this is what we _think_ is happening, as there's no better explanation that we've found. Jeff.
Fw: What is a Dirty Connection (using -Djdbc.debug=true)
I'm forwarding this on to the list as it was very helpful with regard to my question, just incase anyone else has the same questions. Thanks, Avi. Jeff. Begin forwarded message: Date: Tue, 29 Jan 2002 08:50:25 +0200 From: Avi Abrami <[EMAIL PROTECTED]> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Subject: What is a Dirty Connection (using -Djdbc.debug=true) Hi Jeff, I'm not subscribed to the Orion-Interest mailing list, but I monitor it through the OrionServer website. I hope you don't mind that I am answering you via a direct eMail. This is what I know about "dirty connections". (Note that you may already know some of what I am about to tell you, I hope that's OK with you.) Orion "wraps" the JDBC driver classes. It seems to me, from debug messages displayed by the server, (but I haven't verified this yet) that Orion uses different wrapper classes depending on whether the server is running in debug mode or regular mode. I have had my application crash when running in debug mode, but work properly when working in regular (as in non-debug) mode. As far as I can ascertain, a "dirty connection" is one that has an associated "open" Statement or ResultSet or PreparedStatement, etc. object. I have found that the only way to properly "close" a Connection is to first close the ResultSet object, then the Statement object and finally the Connection object. Note that I am only working with the Oracle JDBC driver that comes with OC4J (and my version is 1.0.2.2 -- on SUN Solaris 2.7) Further, the following methods from the JDBC API do not work correctly (when using Orion's JDBC wrapper classes): ResultSet.getStatement() Statement.getConnection() These methods execute normally -- they don't throw exceptions at runtime and they compile without an problems. However, it seems like they do nothing! Basically a "dirty connection" means you have database resources (like Statement objects or ResultSet objects) still lying around -- which need to be disposed of (or "closed"). This is sort of like a memory leak, because eventually the Oracle database will exhaust all its resources and throw SQLExceptions in your application. The only way I found to properly "close" these database resource associated objects (Connection, Statement, ResultSet, etc) was to hold on to the references after I created the objects and only use those references to "close" those objects. So if, for example, you open a Connection in one method and that method returns a ResultSet to a calling method, the calling method will not be able to close the Connection unless you also pass a reference to the Connection to the calling method. Also note, that the Oracle JDBC driver also does not correctly implement the Connection.close() method. According to the API documentation, closing a Connection is supposed to also close any associated Statements, ResultSets, etc. However, the Oracle JDBC driver does not. You need to explicitly close the ResultSet, then the Statement, then the Connection. So in summary, I will answer your questions individually now with a short answer, below: Q:What is a Dirty Connection (when using -Djdbc.debug=true)? A:A connection with unclosed resources lying around. Q:What causes it? A:Not explicitly closing the resources. Q:What repercussions does it have? A:It can crash the database server. Q:Is a Dirty Connection a bad thing? A:Yes. Q:What can we do to avoid it (if anything)? A:Explicitly close all resources -- ResultSets, Statements, etc. Q:Are there any settings that control when and if they are cleaned up? A:If you are using pooled connections, perhaps the "inactivity-timeout" attribute in the "data-sources.xml" file can help -- I don't know for sure. Q:Are they cleaned up at all? A:As far as I can tell, no. A very long post -- I hope you don't mind, and I hope it can help you. Good Luck, Avi. -- Jeff Hubbach Internet Developer Sun Certified Web Component Developer New Media Division ITQ Lata, L.L.C. 303-745-4763 x3114
RE: Servlet reload problem
restart orion -Original Message- From: Tommi Penttilä [mailto:[EMAIL PROTECTED]] Sent: dinsdag 29 januari 2002 12:20 To: Orion-Interest Subject: Servlet reload problem My servlet-classes won't reload. After I recompile changed servlet and http-GET it via orion's (1.5.3) web-interface, orionconsole reports that Servlet was initialized, but I get the same result on browser than before compiling. I did put orion-web-app/@development=true on the web-app-config, but that doesn't help. How do I unload old servlet-classes from memory? Is there anything like Tomcat's context/@reloadable -attribute in Orion? It's extremely annoying to reboot orion every time a servlet class changes. Or maybe I'm just missing something obvious? Any pointers greatly appreciated.
Re: FW: Job Scheduler pattern
why not just run a crontab and forget about having orion fire anything off? Mike Justin Crosbie wrote: [EMAIL PROTECTED]"> This doesn't look like it got processed, I'll send it again...-Original Message-From: Justin Crosbie Sent: 28 January 2002 12:50To: 'Orion-Interest'Subject: RE: Job Scheduler patternHi again,Thanks for the help on this. What I've done so far is this:1. Implemented a java.util.Timer as a Singleton which is accessed from theservlet layer.2. Implemented a class that extends TimerTask, which does a JNDI lookup ofmy EJB and invokes theappropriate method.3. Call the Singleton from the servlet to schedule the TimerTasks as perclient requests.(Plus save details to database)4. Implemented another app to be called via the tag whichreschedules the previouslyscheduled TimerTasks. Thus I have my persistence.5. The Singleton runs the ReScheduler whenever its recreated.6. Run orion using the -userThreads parameter - this is necessary. So, as long as my Singleton class stays up, I should be OK. The problem is,some tasks might be scheduled for weeks or months away. How can I guaranteethat it will fire at the scheduled time even if it is this long away?I understand that there may be several instances of the Singleton perclassloader, thats OK, as long as its a finite amount.So. My question now is: Is this as robust as it gets? Is there anything I amnot doing, or could do to implement a better solution? All opinions welcome.Thanks again,Justin-Original Message-From: Paul Knepper [mailto:[EMAIL PROTECTED]]Sent: 25 January 2002 23:07To: Orion-InterestCc: '[EMAIL PROTECTED]'Subject: RE: Job Scheduler patternJoseph,Very cool. How do you stop a client-module that auto-started and thenrestart it? Say you deployed the app (which also has ejb and web modules) and laterwanted to add another task to the scheduler. Can you start and stop thejava client module, so that it would reload the properties file, withoutaffecting the web module? I might have users logged in to the website and Iwouldn't want to redeploy everthing and messup any current sessions.Thanks,Paul-Original Message-From: Joseph B. Ottinger [mailto:[EMAIL PROTECTED]]Sent: Friday, January 25, 2002 4:04 AMTo: Orion-InterestSubject: Re: Job Scheduler patternThe www.orionsupport.com site has a sample scheduler that can easily beconverted to do something like this.On Fri, 25 Jan 2002, Justin Crosbie wrote: Hi,I'm not sure if I've asked this before, or if I should be asking on ageneral EJB list.I'd like to implement a job scheduler in J2EE. This would shcedule theexecution of EJB methods at a specified time in the future. It would have to be persistent, and jobsd would be rescheduled upon appserver restart.Is it as simple as using the Timer and TimerTask in java.util to implementan app that is started with the tag?Does it matter as far as Orion goes whether I use a java.util.Timer as adaemon or not?What can I do if the app, or the Timer object dies at any stage?I've had problems where after some time something goes wrong I get a strange Remote Exception, and the only solution is to restart the VM. What mightcause this?Any opinions on this? How do I make this solution robust is what I amasking.Thanks for any help,Justin ---Joseph B. Ottinger [EMAIL PROTECTED]http://adjacency.org/ IT Consultant
RE: TX Was Null
Hmm. You potentially have a good point about the transaction retries, I hadn't considered that. I wouldn't have expected the application server to retry with an application-level exception is thrown, though. Do you know that to be the case? I like to keep the validation within the OM for a stronger OOP design, wherein the objects cannot be loaded with invalid data. That said, I've had to make a number of tradeoffs for EJB already, this may be another. I've seen a number of postings where people put snapshots in the value objects, but when you get to that point, EJB just seems as if you're using it for a really clumsy persistence layer instead of true enterprise objects. Our validation helper classes are already re-usable, so I wouldn't gain much there. We also have a CompositeValidationException class with a map of validation errors--interesting to see you went with a similar approach. - Geoffrey : -Original Message- : From: Manuel De Jesus [mailto:[EMAIL PROTECTED]] : Sent: Tuesday, January 29, 2002 2:11 AM : To: Orion-Interest : Subject: RE: TX Was Null : : : I don't think that relying on your Entity Beans for front line data : validation is a good design. As a rule of thumb to get the : best performance : in applications you want to validate as early as you can to : save the trouble : of having to process all the steps for a transaction only to : find the data : is invalid when you want to save things and use this to throw : an error. In : most app servers you usaully set transaction retries to at : least 2 (incase : there was a network/temporary error on the first attempt this : increases the : reliablity) - by throwing data validation exceptions at the : EJB level you : are looking at doing a TX twice before reporting the error : ... terrible : performance. : : What I have done in projects is to abstract validation to a set of : "Validation" classes that are normal java classes which can : be used on the : jsp/ejb etc etc tier. These classes interact with the : database via singleton : caches allowing for dynamic validation updates (worth their : weight in gold). : This also means that the stand alone validation objects can : be easily reused : in other projects, expecially the rules that are generic enough :). : : Using a separate set of validation classes I would suggest: : 1) Validate the TX at the point where it starts right up : front if you are : using jsp etc if this is an option. : 2) Validate the TX in the actual session bean. We use a : custom exception : with a Vector of string mappings that allows us to complain : about more than : one error etc. : 3) If you are really paranoid/have mutiple update points you can also : validate at the entity bean and even a littel at the db level : (not null, : size etc). : : Since you are using a shared validation library, changing the : validation is : done in one place. In addition your application = 100 times : faster since you : are not rolling back transactions a million times over. And : the big bonus is : it will work on 99% of app servers. : : Regards, : Manuel : : : -Original Message- : From: [EMAIL PROTECTED] : [mailto:[EMAIL PROTECTED]]On Behalf Of : [EMAIL PROTECTED] : Sent: Monday, January 28, 2002 5:13 PM : To: Orion-Interest : Cc: [EMAIL PROTECTED] : Subject: TX Was Null : : : We're coming up on our deployment date, so we're considering : our deployment : options (notably, at this point, JBoss and Orion). : : The system is running and working under JBoss, and I've been : re-porting it : to Orion so that we can do some testing, try and resolve some : issues we had : under Orion (for which we got some help from Atlassian that : we haven't had a : chance to try out yet). In the process, we've re-adjusted : most or all of : the finders, and fixed a few bugs here and there between what : JBoss does and : what Orion does. It's been enlightening, as usual. : : That said, we've run up against a brick wall. One of our : transactional : saves uses a session bean to save two entities in a combined : declarative : transaction. Each of these beans can throw validation exceptions when : passed data that's meant to save. We have two unit tests, : one which throws : invalid data into the first object, and another which throws : invalid data : into the second object. : : The second object is relatively easy -- if it has problems, : the session bean : sets the transaction to rollback only, and lets the server do : the rest of : the work. This works under both Orion and JBoss as expected. : : If the first object fails, though, there are larger issues -- : we still want : to find out if there's a problem with the data being passed : to the second : object. Under JBoss, if we tried to do this in the same : transaction, it : complained that the transaction was already rolled back, : which is sensible. : So we put the validation method into a 'requires new' transaction. On
Application Client & JMS
Hi,
i have some problems writing an application client that uses JMS. I have
created a SessionBean which publishes messages and a MDB which receives
the messages. This works fine. I now want to write a client application
that can participate in messaging.
The client connects to the server without problems, but messages
published by the client seem to go nowhere. The MDB does not receive
anything. Also, the client does not receive any messages sent by the
SessionBean.
The directory structure of the client app is:
client
+--- MessageMonitor.class
+--- META-INF
+---application-client.xml
+---orion-application-client.xml
The application-client.xml:
...
jms/TopicConnectionFactory
javax.jms.TopicConnectionFactory
Container
jms/BenelogNewOrder
javax.jms.Topic
Container
where "BenelogNewOrder" is the name of the Topic I would like to
subscribe to.
The client looks up the Topic using something like:
lookup("java:comp/env/jms/BenelogNewOrder");
Please give me some hint what i am doing wrong. Also, any informations
where to find more about app-clients & Orion is appreciated. Neither
orion nor atlassian seem to have tutorials on this topic.
Thanks in advance!
Jochen
--
-
Jochen Kressin
[EMAIL PROTECTED]
Interested in distributed computing?
http://www.jeremi.org
FW: Job Scheduler pattern
This doesn't look like it got processed, I'll send it again... -Original Message- From: Justin Crosbie Sent: 28 January 2002 12:50 To: 'Orion-Interest' Subject: RE: Job Scheduler pattern Hi again, Thanks for the help on this. What I've done so far is this: 1. Implemented a java.util.Timer as a Singleton which is accessed from the servlet layer. 2. Implemented a class that extends TimerTask, which does a JNDI lookup of my EJB and invokes the appropriate method. 3. Call the Singleton from the servlet to schedule the TimerTasks as per client requests. (Plus save details to database) 4. Implemented another app to be called via the tag which reschedules the previously scheduled TimerTasks. Thus I have my persistence. 5. The Singleton runs the ReScheduler whenever its recreated. 6. Run orion using the -userThreads parameter - this is necessary. So, as long as my Singleton class stays up, I should be OK. The problem is, some tasks might be scheduled for weeks or months away. How can I guarantee that it will fire at the scheduled time even if it is this long away? I understand that there may be several instances of the Singleton per classloader, thats OK, as long as its a finite amount. So. My question now is: Is this as robust as it gets? Is there anything I am not doing, or could do to implement a better solution? All opinions welcome. Thanks again, Justin -Original Message- From: Paul Knepper [mailto:[EMAIL PROTECTED]] Sent: 25 January 2002 23:07 To: Orion-Interest Cc: '[EMAIL PROTECTED]' Subject: RE: Job Scheduler pattern Joseph, Very cool. How do you stop a client-module that auto-started and then restart it? Say you deployed the app (which also has ejb and web modules) and later wanted to add another task to the scheduler. Can you start and stop the java client module, so that it would reload the properties file, without affecting the web module? I might have users logged in to the website and I wouldn't want to redeploy everthing and messup any current sessions. Thanks, Paul -Original Message- From: Joseph B. Ottinger [mailto:[EMAIL PROTECTED]] Sent: Friday, January 25, 2002 4:04 AM To: Orion-Interest Subject: Re: Job Scheduler pattern The www.orionsupport.com site has a sample scheduler that can easily be converted to do something like this. On Fri, 25 Jan 2002, Justin Crosbie wrote: > Hi, > > I'm not sure if I've asked this before, or if I should be asking on a > general EJB list. > > I'd like to implement a job scheduler in J2EE. This would shcedule the > execution of EJB methods at a specified time in the future. It would have to > be persistent, and jobsd would be rescheduled upon appserver restart. > > Is it as simple as using the Timer and TimerTask in java.util to implement > an app that is started with the tag? > > Does it matter as far as Orion goes whether I use a java.util.Timer as a > daemon or not? > > What can I do if the app, or the Timer object dies at any stage? > > I've had problems where after some time something goes wrong I get a strange > Remote Exception, and the only solution is to restart the VM. What might > cause this? > > Any opinions on this? How do I make this solution robust is what I am > asking. > > Thanks for any help, > Justin > --- Joseph B. Ottinger [EMAIL PROTECTED] http://adjacency.org/ IT Consultant
Servlet reload problem
My servlet-classes won't reload. After I recompile changed servlet and http-GET it via orion's (1.5.3) web-interface, orionconsole reports that Servlet was initialized, but I get the same result on browser than before compiling. I did put orion-web-app/@development=true on the web-app-config, but that doesn't help. How do I unload old servlet-classes from memory? Is there anything like Tomcat's context/@reloadable -attribute in Orion? It's extremely annoying to reboot orion every time a servlet class changes. Or maybe I'm just missing something obvious? Any pointers greatly appreciated.
RE: cgi question [EXPIRED TRIAL LICENCE]
If you look in the global-web-application.xml, you will see that there is a cgi servlet. If you want to use your own php engine, you will need to do something like this: php com.evermind.server.http.CGIServlet interpreter /usr/local/bin/php There are some issues, though, on how you would compile the php engine. Here is something that is proported to work: ./configure --with-mysql=/usr --disable-force-cgi-redirect --enable-force-cgi-redirect=/etc/openldap --without-gd --enable-calendar --e nable-discard-path --enable-trans-sid --with-openssl --with-imap --enable-inline-optimization This is from Andraas Mag. Regards, the elephantwalker www.elephantwalker.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of orionDummy Sent: Monday, January 28, 2002 7:36 PM To: Orion-Interest Subject: cgi question [EXPIRED TRIAL LICENCE] Does anyone know if orion can server cgi and what needs to be done if so. Thanks
