Author |
Message
|
MB_MY_RELIGION |
Posted: Mon May 02, 2011 11:34 am Post subject: Updating MB Cache without impacting inflight messages |
|
|
Newbie
Joined: 25 May 2009 Posts: 5
|
Is there a way to update the MB cache without impacting in-flight messages? This will rule out option to reload execution group. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon May 02, 2011 11:44 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
Yes, cache objects can be refreshed on-demand. There are several ways to do this. One is create a custom classloader. If you look at JCN properties, you can specify a "Java classloader service". Your custom classloader can reload a class on-the-fly, on-demand. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
mqjeff |
Posted: Mon May 02, 2011 11:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
lancelotlinc wrote: |
Yes, cache objects can be refreshed on-demand. There are several ways to do this. One is create a custom classloader. If you look at JCN properties, you can specify a "Java classloader service". Your custom classloader can reload a class on-the-fly, on-demand. |
This assumes several things, include what kind of 'cache' that MB_MY_RELIGION means...
Also, a Java Classloader service is a JavaClassLoader broker configurable service, and does not allow you to for example specify that a particular JCN should use a different class for it's classloader. It just allows you to create a specific instance of a Named classloader and configure it with certain values for directories. EDIT: and then you can configure the JCN to use this specific Named classloader for it's classloading... but not a user developed classloader.
And of course is only usable from Broker v7....
MB_MY_RELIGION... To what do you refer when you say "the MB cache"? |
|
Back to top |
|
 |
MB_MY_RELIGION |
Posted: Mon May 02, 2011 12:54 pm Post subject: |
|
|
Newbie
Joined: 25 May 2009 Posts: 5
|
By Cache I mean Shared Row. Which was initialized with details. Now I want to implement a way in which I can update the shared row without impacting in-flight messages |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon May 02, 2011 1:03 pm Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
@mqjeff:
In my "for instance" example, I would use the same name for the class, but could load a newer version of that class on-the-fly, on-demand without bouncing the broker or message flow. The source of the class could be a file server someplace on the network. So, if I wanted, I could publish a new version of the class to the file server, flip a switch, and have the custom classloader reload the class to begin new functionality.
Thus, in-flight messages would process without interruption. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
lancelotlinc |
Posted: Mon May 02, 2011 1:04 pm Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
MB_MY_RELIGION wrote: |
By Cache I mean Shared Row. Which was initialized with details. Now I want to implement a way in which I can update the shared row without impacting in-flight messages |
I would not use Shared Row implementation to store cache objects in memory.
Use a Singleton instead (simple, quick and dirty).
If you want a more elegant solution, use solidDB. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
Vitor |
Posted: Mon May 02, 2011 3:30 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
lancelotlinc wrote: |
MB_MY_RELIGION wrote: |
By Cache I mean Shared Row. Which was initialized with details. Now I want to implement a way in which I can update the shared row without impacting in-flight messages |
I would not use Shared Row implementation to store cache objects in memory. |
But the OP did, and that's the construct for which advice is being sought.
lancelotlinc wrote: |
Use a Singleton instead (simple, quick and dirty).
If you want a more elegant solution, use solidDB. |
Irrespective of the dirt or elegance of any alternative solution, in worlds other than yours people are employed to fix the solution as designed not redesign it. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
rekarm01 |
Posted: Mon May 02, 2011 5:04 pm Post subject: Re: Updating MB Cache without impacting inflight messages |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
MB_MY_RELIGION wrote: |
By Cache I mean Shared Row. Which was initialized with details. Now I want to implement a way in which I can update the shared row without impacting in-flight messages |
If one or more sections of code contains multiple read/write operations that need to be atomic, enclose them in BEGIN ATOMIC ... END statements.
If a message flow reads the shared row multiple times, and needs the row to be constant throughout the transaction, first copy the shared row to a non-shared row, and then read the non-shared row multiple times instead. |
|
Back to top |
|
 |
MB_MY_RELIGION |
Posted: Mon May 02, 2011 5:05 pm Post subject: |
|
|
Newbie
Joined: 25 May 2009 Posts: 5
|
Guys,
Help me out here on how to update share row on the fly without impacting in flight messages |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon May 02, 2011 8:11 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
MB_MY_RELIGION wrote: |
Guys,
Help me out here on how to update share row on the fly without impacting in flight messages |
What part of rekarm01's last advice did you not understand?
You can have an additional input node, that would trigger a refresh of the shared row within an ATOMIC statement.... Like rekarm01 said if you need the values to be constant for the duration of the flow, copy them from the shared area to a private (non shared) area using the ATOMIC statement and then read them from the private area...
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mqjeff |
Posted: Tue May 03, 2011 2:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
lancelotlinc wrote: |
@mqjeff:
In my "for instance" example, I would use the same name for the class, but could load a newer version of that class on-the-fly, on-demand without bouncing the broker or message flow. The source of the class could be a file server someplace on the network. So, if I wanted, I could publish a new version of the class to the file server, flip a switch, and have the custom classloader reload the class to begin new functionality.
Thus, in-flight messages would process without interruption. |
What I said, mainly, was that the JavaClassLoader configurable service does not allow you to create a custom classloader. It merely allows you to provide information to a specific instance of the NamedClassloader class that Broker uses.
You can certainly write your JCN to make use of a custom classloader. But the use of a JavaClassLoader configurable service has no relationship to that.
And that's really the very long way to go around to deal with anything. In general, any time you are writing your own classloader, you are likely coding yourself into a box you won't fit later. |
|
Back to top |
|
 |
rekarm01 |
Posted: Tue May 03, 2011 5:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 1415
|
fjb_saper wrote: |
What part of rekarm01's last advice did you not understand? |
To be fair, less than a minute had elapsed between that post and the preceding one; it's likely that MB_MY_RELIGION hadn't seen it before posting.
MB_MY_RELIGION wrote: |
Guys,
Help me out here ... |
On the other hand, the participants of this forum live in different timezones, and are donating their free time to offer free advice. It might be prudent to wait more than six hours before prodding them to work faster. |
|
Back to top |
|
 |
Vitor |
Posted: Tue May 03, 2011 6:07 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
rekarm01 wrote: |
On the other hand, the participants of this forum live in different timezones, and are donating their free time to offer free advice. It might be prudent to wait more than six hours before prodding them to work faster. |
 _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|