| Author |
Message
|
| visasimbu |
 Posted: Thu Jan 13, 2011 8:51 am Post subject: jar file in shared class |
 |
|
Disciple
Joined: 06 Nov 2009
Posts: 171
|
Hi all,
i have done select query in my java file and saved it in object ( i.e MbElement object). So from the next transaction flow will refer the data which is in object. In this manner i have implemented the cache.
But it is not working as my expectation.
For first message, it was accessing db and selected the entries.
For second message, it was taking values from the object and doing needed operation.
From third message, it is not working as my expectation.
I dont know whether data in the object is deleted or object got dead.
Any one know how to implement the cache in java file in shared class path.
or
Where i did mistake in my flow ?
Please help me. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Jan 13, 2011 8:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It is a horrible horrible idea to store an MbElement object, that references a component of the logical message tree that only exists inside a single instance of a message flow, and attempt to use it in any other instance of a message flow.
Stop right now. Abandon your code. Do not write further Java Compute node code until you understand enough about Broker to make sensible decisions.
Go to the SupportPacs page, download the IA91 supportPac, use it instead of trying to reinvent the "round thing at the end of an axle". |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Jan 13, 2011 11:43 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
I agree with part A of mqjeff's recommendation. Seems you need some expert consultant to help you with this.
I respectfully disagree with using the IA91 support pak. Its buggy and not supportable in a production environment.
The right approach is to use a JAR/Singleton object in shared classes as you attempted. But it doesn't seem that your experience is deep enough to make it work. Ask for help from a more senior resource.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 13, 2011 11:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| I respectfully disagree with using the IA91 support pak. Its buggy and not supportable in a production environment. |
I accept that this is a Cat 2 support pac, but that's a little harsh. I trust you've fed your experiences back to the author?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Jan 13, 2011 12:13 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
The feedback was provided through the client. It would be supportable if IBM released the source code or provided support as a regular part of the license rather than charge extra for it.
If you dig into the Support pak, you will notice that the support pak uses a JAR/Singleton just like the OP was trying to do for intraprocess communication and uses queues for inter-process communication.
If a production outage occurs due to the component, there is nothing that anyone can do to fix it. So, while I truly do support COTS approach to software, this is an instance where the only way to truly support your cache in production is to own your own source code.
Cache data is typically used to make decisions and save latency time from hitting the database with every message. Its great when it works, but when something gets fowled up, the wrong decision tree can be run through due to stale cache data. Therefore, if you are going to design your application to use cache data, better to use SolidDB if you can afford it or write your own Singleton if you can't.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jan 13, 2011 6:50 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
The feedback was provided through the client. It would be supportable if IBM released the source code or provided support as a regular part of the license rather than charge extra for it.
If you dig into the Support pak, you will notice that the support pak uses a JAR/Singleton just like the OP was trying to do for intraprocess communication and uses queues for inter-process communication.
If a production outage occurs due to the component, there is nothing that anyone can do to fix it. So, while I truly do support COTS approach to software, this is an instance where the only way to truly support your cache in production is to own your own source code.
Cache data is typically used to make decisions and save latency time from hitting the database with every message. Its great when it works, but when something gets fowled up, the wrong decision tree can be run through due to stale cache data. Therefore, if you are going to design your application to use cache data, better to use SolidDB if you can afford it or write your own Singleton if you can't. |
I agree with all of that.
Except for the part where you assume that visasimbu has demonstrated the necessary skills to understand the difference between what I have said and what you have said.
 |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Jan 14, 2011 5:18 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
@mqjeff
I admire the OP's gumption for trying something new and cutting edge in his/her code.
I am in alignment with you that the OP needs some guidance from someone who has done cutting edge stuff before. And I think I mentioned that the OP should seek out a more senior resource.
If I were asked to review the OP's code, I would first look to see how he/she is constructing the Singleton object. The OP said the cache connection to DB "got dead". I wonder if the OP has read this article about Singletons:
http://en.wikipedia.org/wiki/Singleton_pattern
Here is another good article on Singletons:
http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html
My best wishes to all!
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| visasimbu |
| Posted: Sun Jan 16, 2011 1:13 am Post subject: |
|
|
Disciple
Joined: 06 Nov 2009
Posts: 171
|
Thanks to lancelotlinc, mqjeff and Vitor.
I have implemented singleton in my code. Now it is working as per my expectation.
Special Thanks to lancelotlinc. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jan 18, 2011 5:43 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Congratulations Visasimbu! You did it.
I would encourage you to think differently much more often than the status quo. Outside-the-box thinking is what will deliver unexpected and outstanding results to you in many ways you never thought of before. It will open new possibilities and create opportunities that you did not see coming.
Using Singleton in a Jar and calling from JCN is just one example of something that can be done creatively that not many people thought about. Sensai says "Grasshopper, think is simple terms, simplicity brings swiftness of feet."
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jan 18, 2011 5:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| Using Singleton in a Jar and calling from JCN is just one example of something that can be done creatively that not many people thought about. |
It should have been the first thing any competent and trained Java programmer reached for. It's only been part of the common java patterns for, what... 15 years?
And anyone with a decent smattering of Message Broker development skills would have never tried to stick an MbElement into a Singleton. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jan 18, 2011 7:28 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Visasimbu, for extra credit, you could implement a JMX MBean interface to your Singleton which would display the various states of things in your Singleton via jconsole.
@mqjeff
Sir, please be patient with us. We are poor students and only want to explore and learn.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jan 18, 2011 7:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
@mqjeff
Sir, please be patient with us. We are poor students and only want to explore and learn. |
The time for patience to end when teaching students how to drive automobiles is when they have turned the car 90 degrees to the direction of the road.
Similarly, the time for patience to end when teaching students how to write Java code in Message Broker is when they try and use an MbElement outside the instance of the message flow that created it.
Thirdly, this forum IS NOT A TRAINING RESOURCE. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jan 18, 2011 7:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Sir, please be patient with us. We are poor students and only want to explore and learn. |
And there are a number of providers offering excellent training courses. We are not among them. This is a technical forum, we're not set up for training.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu Jan 20, 2011 1:41 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
 I liked this!
But I do not understand the bitter comments about training. I can assure you the subject was by no means trivial.
| Vitor wrote: |
And there are a number of providers offering excellent training courses. We are not among them. |
As a (retired) instructor on IBM courses I would say neither is IBM. There is no relevant course material about using java with Message Broker.
Well, as some of you may have noticed the hard way, Message Broker and a java "guru" is often a catastrophic combination. To be successful with java and Message Broker you will have to master both of them before you start combining things.
I was actually running a private training related to my current freelance contract when we sidetracked to discussing outsourcing to India (a hot topic to my customer). It seems to be a common experience about India that after receiving very imaginatively written CV's you will have to struggle with newbies, incompetence and lack of initiative. I made a remark that there seem to be at least some competent indians around by now and to prove my claim I opened mqseries.net and started to browse for typical indian user names.
And I happened to open this thread! Wow!
Some years ago there were some performance report support packs comparing java and ESQL. And they always ended up claiming that ESQL outperforms java. This was, quite probably, due to the fact that the people that run the evaluations were very experienced ESQL programmers but novices with java (less than three years of java experience I would guess). My personal experience has been that in skilled hands java clearly outperforms ESQL. But to achieve this you will have to use it in ways that often seem very unconventional to people accustomed to procedural programming languages like ESQL.
Well, there is one thing java is not always the best solution for and that is - message transformation. You will get three times more lines of code than with ESQL. But nothing beats java when you will have to create a well-performing configurable Message Broker framework where you just plug in your transformation written using any of the alternatives available!
Bravo, visasimbu and Sir Lancelot Getahaircut! This was a visionary, eye-opening and entertaining thread! |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Jan 20, 2011 1:58 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Quote: |
| It seems to be a common experience about India that after receiving very imaginatively written CV's you will have to struggle with newbies, incompetence and lack of initiative. I made a remark that there seem to be at least some competent indians around by now and to prove my claim I opened mqseries.net and started to browse for typical indian user names. |
Over the past month I've had more then 50 CV pass over my desk. 99% were Indians with years of experience in everything under the sun and all proclaiming to be experts in all things Websphere. Many were only in a role for a maximum of 3 months at a time. Does that strike you as a little suspect.
We invited a few to interviews. Of the 6 who accepted only one bothered to turn up. 15 minutes into the technical part he started bulshitting me. Rather than say, 'I'm sorry, I don't know' he blustered around digging the whole he was in ever deeper. He didn't get the job.
We also use an Indian outsourcer. They are a disaster waiting to happen. Thankfully senior management are wising up to them and they will soon be gone. I know this is being general but that is just my experience. On the otherhand, there are some real whizzes from the Sub-continent. Worth as much as any Westerner. It is a funy old world.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
