Author |
Message
|
reachsatish |
Posted: Wed Jul 18, 2007 6:21 pm Post subject: Is Java static variables shared across message flow? |
|
|
Newbie
Joined: 18 Jul 2007 Posts: 6
|
We plan to use the Java static variables to cache data to minimize database access. This data is common across various message flows. Does WMB shares the Java static variables (Has one copy of data that is accessibel from all the message flows)?
What are the other methods of caching the data in a Java Computer Node.
Thanks
Satish |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Jul 18, 2007 7:13 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Every execution group is it's own JVM. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
christian witschel |
Posted: Sun Jul 22, 2007 11:17 pm Post subject: Re: Is Java static variables shared across message flow? |
|
|
Apprentice
Joined: 07 Dec 2005 Posts: 27
|
reachsatish wrote: |
We plan to use the Java static variables to cache data to minimize database access. This data is common across various message flows. Does WMB shares the Java static variables (Has one copy of data that is accessibel from all the message flows)?
What are the other methods of caching the data in a Java Computer Node.
Thanks
Satish |
Hi,
try to use the GlobalEnvironment in Broker 6.0.
Apart from that there is the usual stuff: Files, Database and Messages in a queue. |
|
Back to top |
|
 |
Vitor |
Posted: Sun Jul 22, 2007 11:57 pm Post subject: Re: Is Java static variables shared across message flow? |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
christian witschel wrote: |
try to use the GlobalEnvironment in Broker 6.0.
Apart from that there is the usual stuff: Files, Database and Messages in a queue. |
Don't store this sort of thing as messages in a queue. It's not good and you'll have trouble.
The other options are much better. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
marcin.kasinski |
Posted: Mon Jul 23, 2007 1:09 am Post subject: Re: Is Java static variables shared across message flow? |
|
|
Sentinel
Joined: 21 Dec 2004 Posts: 850 Location: Poland / Warsaw
|
reachsatish wrote: |
We plan to use the Java static variables to cache data to minimize database access. This data is common across various message flows. Does WMB shares the Java static variables (Has one copy of data that is accessibel from all the message flows)?
What are the other methods of caching the data in a Java Computer Node.
Thanks
Satish |
You can use JAVA singleton to store this information.
Then you can access this JAVA singleton by JAVA Compute or inside your ESQL by JAVA EXTERNAL procedure. _________________ Marcin
Last edited by marcin.kasinski on Mon Jul 23, 2007 2:18 am; edited 1 time in total |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Jul 23, 2007 1:39 am Post subject: Re: Is Java static variables shared across message flow? |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
christian witschel wrote: |
try to use the GlobalEnvironment in Broker 6.0. |
The GlobalEnvironment in v6 is the same as it was in v2.1.
It is not shared between invocations of a message flow. So it can't be used for this.
 _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
valined |
Posted: Mon Sep 17, 2007 6:38 am Post subject: And the winner is... |
|
|
Newbie
Joined: 16 Sep 2007 Posts: 2
|
So who is the winner?
I'm really curious.
[NOTE: static variables are not automatically shared among different JVMs, so -as I understand- different execution groups will have different values for static variables] |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Sep 17, 2007 7:08 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Winner for what?
The environment tree is not shared between invocations of a single message flow.
ESQL shared variables are not shared between different message flows, and can't be accessed from Java.
Java static variables are not shared between different JVMs. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
valined |
Posted: Mon Sep 17, 2007 10:52 pm Post subject: |
|
|
Newbie
Joined: 16 Sep 2007 Posts: 2
|
jefflowrey wrote: |
Winner for what?
|
Sorry for not being more clear.
I was referring to the OP's initial intent, to cache data retrieved from a RDBMS.
So the question is: what's the winner (right/recommended/best practice) technique to share data retrieved from DB, possibly amongst different execution groups? |
|
Back to top |
|
 |
elvis_gn |
Posted: Tue Sep 18, 2007 12:45 am Post subject: |
|
|
 Padawan
Joined: 08 Oct 2004 Posts: 1905 Location: Dubai
|
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Sep 18, 2007 2:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Because everyone wants to reinvent the wheel!
Yes, IA91 is an excellent solution to this. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
christian witschel |
Posted: Wed Sep 19, 2007 4:55 am Post subject: |
|
|
Apprentice
Joined: 07 Dec 2005 Posts: 27
|
Or mayby because IBM does not tell anybody that the banana just turned a little more from green to yellow. I hate support packs that add stuff that should be already in the main product.
But IA91 sounds good. I will test it. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Sep 19, 2007 4:57 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
christian witschel wrote: |
I hate support packs that add stuff that should be already in the main product. |
Patience. I remember when Java support was a support pac...  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Sep 19, 2007 5:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
The whole point of SupportPacs is to provide features that aren't in the main product - either because product development doesn't have the time to put the feature in, or because product development didn't see the need.
A clear example of this is the MQGet node. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
|