| Author |
Message
|
| whydieanut |
 Posted: Mon Jun 09, 2014 4:15 am Post subject: Use of of Java Singleton or Static object in WMB |
 |
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
Hi all,
I have a requirement wherein I need to make use of a Java utility to make Database look-ups in my flow. I have created a Java project to make use of the existing utility to connect to and query the DB, and am calling a static method through ESQL.
I pass my DB parameters like schema name, user id and query parameters through the Environment Tree and retrieve the results in the Environment Tree as well.
Everything is working fine so far.
Now the utility consists of creating an object of 'ClassA', with a method to retrieve credentials for the DB, and then creating an object of another class, 'ClassB', to make the actual query using the credentials retrieved.
So I end up creating an object of each, every time I call my Java method.
What would be a better way to handle this, so that I can retain those objects for longer, and also have the ability to flush them when required?
I tried making the objects static, but I couldn't get them to lose their value even after restarting the flow. Is this a good use case for using Singletons?
If I am being unclear on something, please let me know. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Jun 09, 2014 4:27 am Post subject: Re: Use of of Java Singleton or Static object in WMB |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| whydieanut wrote: |
| If I am being unclear on something, please let me know. |
Why are you using a Java utility to perform something WMB can do itself? What's the use case here? Do not reply "because that's my requirement" - what's the technical reason?
Why especially are you using "classA" to retrieve credentials and therefore building the functionality of the broker registry in code? What's wrong with the IBM wheel that you need to invent your own?
Basic point to your original question - WMB is not WAS. Object handling and memory management do not fit that model, due to the fact that all the Java is an extension of the root JCN class and the scope of the object is more than the scope of your flow.
Singletons might enable you to bend this flawed solution to a point where it works but I would still doubt a number of aspects of this; noteably scalability and long term supportablity.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 09, 2014 4:28 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You might also consider how secure your db credentials are, if any instance of "classA" can retrieve them......
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| McueMart |
| Posted: Mon Jun 09, 2014 5:12 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
Well I echo what Vitor is saying about storing username/password in your own code (if that's what you are doing?); But if you simply wanted to "cache" the query string, I can see no issue with using a Java Singleton, or a static class , which simply has a 'clearCache()' method which you can invoke when needed.
The reason the Static objects didnt lose their values is that the JVM is EG wide (Stopping an application/flow wont do anything!). Restating the EG would cause the static objects to lose their values. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 09, 2014 5:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| McueMart wrote: |
| The reason the Static objects didnt lose their values is that the JVM is EG wide (Stopping an application/flow wont do anything!). Restating the EG would cause the static objects to lose their values. |
Which is the more technical (and accurate) way of making my point about things not working the same in Java land. Thank you.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 09, 2014 5:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| And there are several other ways, without restarting the EG, that your singletons can get reinitialized. |
|
| Back to top |
|
|
| whydieanut |
| Posted: Mon Jun 09, 2014 6:22 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
| Vitor wrote: |
Why are you using a Java utility to perform something WMB can do itself? What's the use case here? Do not reply "because that's my requirement" - what's the technical reason?
Why especially are you using "classA" to retrieve credentials and therefore building the functionality of the broker registry in code? What's wrong with the IBM wheel that you need to invent your own? |
I know it's a very convoluted way of doing things.
We were using stored procs to do it earlier, but we have been asked to move to this approach by the guys handling the DB, and I am not aware of the reason for this. 
| Vitor wrote: |
Basic point to your original question - WMB is not WAS. Object handling and memory management do not fit that model, due to the fact that all the Java is an extension of the root JCN class and the scope of the object is more than the scope of your flow.
Singletons might enable you to bend this flawed solution to a point where it works but I would still doubt a number of aspects of this; noteably scalability and long term supportablity. |
The fact is I can't work around the limitations of using the Java utility to access the DB, and the am trying to modify the existing procedure so that it's more elegant than it is now. So if there is any way of reducing the overhead of creating the connection object and for every call, that will really help, but I don't want to do it at the cost of introducing more trouble at a later time.
| McueMart wrote: |
| Well I echo what Vitor is saying about storing username/password in your own code (if that's what you are doing?); But if you simply wanted to "cache" the query string, I can see no issue with using a Java Singleton, or a static class , which simply has a 'clearCache()' method which you can invoke when needed. |
I am only storing the user name in Code (UDP actually); the password is retrieved every time the function is called. Again I am not really sure if I should store the password in memory
And it's not the query string that needs to be cached, it's a client object that makes the actual call, with the supplied query string, that I am trying to cache.
| McueMart wrote: |
| The reason the Static objects didnt lose their values is that the JVM is EG wide (Stopping an application/flow wont do anything!). Restating the EG would cause the static objects to lose their values. |
I figured an EG restart might do the job, will try that.
| Vitor wrote: |
| And there are several other ways, without restarting the EG, that your singletons can get reinitialized. |
Could you help me out as to where I can find more info about this? Wasn't very successful searching online yesterday.
So... If I do end up having to do it, is it better to declare those objects as static members in my Java proj, or is it better to create my Java class as a singleton? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jun 09, 2014 7:57 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
As far as connection is concerned, you should drop your approach and really look at configurable services for creating the jdbc type 4 connection.
Really read up on the infocenter, I believe the sql statement (prepare) gets cached by default...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sunny_30 |
| Posted: Mon Jun 09, 2014 12:50 pm Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
| fjb_saper wrote: |
| As far as connection is concerned, you should drop your approach and really look at configurable services for creating the jdbc type 4 connection. |
Yes, as guru fjb_saper says, manage connections using configurable services (inside JCN). If you have to invoke external methods from ESQL to use these connections, store these connections in ThreadLocal which enables to define a static variable instance specific to every message-flow thread. |
|
| Back to top |
|
|
|
|
