| Author |
Message
|
| Angshuman |
 Posted: Thu Oct 03, 2013 10:54 pm Post subject: How broker maintains GlobalCache |
 |
|
Apprentice
Joined: 30 Apr 2009
Posts: 29
|
Hi,
I am still trying to understand, how and where does broker stores the Key-value in global cache. It cannot be JVM hashmaps as every EGs (Integration Server) have isolated JVM. Does it internally store in the SYSTEM BROKER queue. I am not able to get much information about it in infocenter. Can someone help.
Regards,
Angshuman |
|
| Back to top |
|
 |
| Simbu |
| Posted: Thu Oct 03, 2013 11:08 pm Post subject: |
|
|
Master
Joined: 17 Jun 2011
Posts: 289
Location: Tamil Nadu, India
|
IIB(WMB) uses embedded WebSphere eXtreme Scale or external WXS or XC10 for global cache.
| Quote: |
| WebSphere eXtreme Scale uses grids to store data that you want to reuse. |
Best to check the respective product infocenter for more help on this. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Oct 03, 2013 11:38 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
AFAIK, Broker uses a SUBSET of the eXtreme Scale Cache product.
Not all the features of this are available in the broker implementation.
Again, AFAIK, the Cash is a Java Hashmap as it is implemented on an EG wide basis and there is code that links the various containers together.
_________________
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 |
|
|
| Angshuman |
| Posted: Fri Oct 04, 2013 1:07 am Post subject: |
|
|
Apprentice
Joined: 30 Apr 2009
Posts: 29
|
|
| Back to top |
|
|
| Simbu |
| Posted: Fri Oct 04, 2013 1:29 am Post subject: |
|
|
Master
Joined: 17 Jun 2011
Posts: 289
Location: Tamil Nadu, India
|
| Quote: |
Maps
Data is stored in maps. A map is a data structure that maps keys to values. One map is the default map, but the global cache can have several maps.
The cache uses WebSphere eXtreme Scale dynamic maps. Any map name is allowed, apart from names that begin with SYSTEM.BROKER, which is reserved for use by the broker. The default map is named SYSTEM.BROKER.DEFAULTMAP; you can use or clear this map. |
|
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Oct 04, 2013 1:39 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I agree.
In my cache at the moment there are two main MAPS
S_DEALER
S_MODEL
_________________
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 |
|
|
| lancelotlinc |
| Posted: Fri Oct 04, 2013 3:31 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
"It cannot be JVM hashmaps"
This is incorrect. The underlying primitive is in fact a network-enabled Java hashmap hosted by a Singleton in what is called a Grid. This Grid has what is called 'Shards'. Each Shard is hosted in a process, for WMB, this means Execution Group. The Shards communicate with each other so that all shards have the same information, in what we know as a cache. There is a policy xml file that dictates to each Shard how its maps post that information to the other Shards (two-phase commit, with pessimistic locking).
| Quote: |
A data grid is divided into partitions. A partition holds an exclusive subset of the data. A partition contains one or more shards: a primary shard and replica shards. Replica shards are not necessary in a partition, but you can use replica shards to provide high availability. Whether your deployment is an independent in-memory data grid or an in-memory database processing space, data access in eXtreme Scale relies heavily on shards.
The data for a partition is stored in a set of shards at run time. This set of shards includes a primary shared and possibly one or more replica shards. A shard is the smallest unit that eXtreme Scale can add or remove from a Java virtual machine.
Two placement strategies exist: fixed partition placement (default) and per container placement. The following discussion focuses on the usage of the fixed partition placement strategy. |
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| iShakir |
| Posted: Mon Oct 07, 2013 12:48 am Post subject: |
|
|
Apprentice
Joined: 07 Mar 2013
Posts: 47
|
What do you require this understanding for?
My experience is that if you consider the programming interface as simply a HashMap that is accessible cross-JVM, then you shouldn't have too many conceptual problems. Unless there's some particular nuance you've come across?
In terms of administrating the cache. I would consider reviewing the documentation for the global cache in the infocentre. At this stage it will speak a dialect more focused around Websphere eXtremeScale (it will talk catalog servers and container servers at you). You may need to do some research into how it claims to function. |
|
| Back to top |
|
|
|
|
