[SGF-88] Create Regions in Spring Context with Region Shortcuts Created:
19/Apr/12 Updated: 21/Sep/14 Resolved: 21/Mar/14
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Closed
Spring Data GemFire
None
1.1.1
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Improvement
Dave Roberts
Complete
None
Not Specified
Last updater:
John Blum
1.4 M1 (Dijkstra)
Priority:
Assignee:
Votes:
Major
John Blum
0
Not Specified
Not Specified
Description
Traditional Gemfire configuration via the cache.xml allows for regions to be created with region shortcuts.
See
http://www.gemstone.com/docs/current/product/docs/japi/com/gemstone/gemfire/cache/RegionShortcut.html
For migration purposes and ease of use this facility should also exist within a Spring context, otherwise the
definition of the region must stay in the cache.xml. I can see this working in the same way that client regions
support shortcuts.
Comments
Comment by Dave Roberts [ 19/Apr/12 ]
This is needed for both replicated regions and partitioned regions
Comment by Dave Roberts [ 04/May/12 ]
This also ties in with the need for comprehensive namespace capabilities from a region
perspective. For instance, there is no support for local regions.
Take this cache.xml as an example:
<cache>
<region name="exampleRegion"/>
</cache>
there is no <gfe:local-region/> capability
Comment by David Turanski [ 31/May/12 ]
Shortcuts create issues with mutually exclusive attributes. A better approach is to provide bean
inheritance for regions with the ability to create abstract region definitions and a parent
reference. Also we could add a <region-shortcuts/> element to create the default abstract regions
(with an optional location attribute to override the defaults)
Comment by David Turanski [ 25/Jul/12 ]
<local-region> will be in 1.2.0.RC1. Shortcuts are not supported, but every configuration
offered by shortcuts should be easily done in the namespace.
Comment by John Blum [ 06/Nov/13 ]
I like David's suggestions from May 31st, 2013. This is also similar to what has been requested
in SGF-207.
The main problem, or benefit I see, depending on how you look at it, is Spring Data GemFire
provides appropriate abstractions for GemFire's Region Shortcuts and Data Policy types already.
For instance, SDG has the following Region elements for peer Caches...
<gfe:partitioned-region .../>
<gfe:replicated-region .../>
<gfe:local-region .../>
<gfe:lookup-region/>
lookup-region
is really only applicable if you are using GemFire's native cache.xml to define
your configuration (and specifically your Regions) in addition to the SDG XML namespace, and
so does not support Data Policies or Region Shortcuts.
These SDG XML namespace Region element abstractions for the various GemFire Region
types (or rather Data Policy defined Regions in GemFire) would actually limit what sort of
"shortcut" would actually apply to the, shall we say, "strongly-typed" SDG defined GemFire
Region.
For instance, if I declared a Partitioned Region using <gfe:partitioned-region .../>, then
I have already set the GemFire Data Policy to 1 of [PARTITION, PERSISTENT_PARTITION]
depending on the value of the persistent attribute. It is possible to specify the data-policy
and/or persistent attributes on the various SDG XML namespace Region element abstractions
independently or collectively, but now they all have to agree, and agree with their element type.
I.e. it is not possible to define a Region in SDG config using the XML namespace like so
<gfe:partitioned-region persistent="false" datapolicy="PERSISTENT_REPLICATE"/>. Doing so results in an
error due to the ambiguity
concerning what the user meant.
In addition, while defining a Partitioned Region as <gfe:partitioned-region
id="appData"/> enables the following Region shortcuts to be used...
PARTITION,
PARTITION_REDUNDANT,
PARTITION_PERSISTENT,
PARTITION_REDUNDANT_PERSISTENT,
PARTITION_OVERFLOW,
PARTITION_REDUNDANT_OVERFLOW,
PARTITION_PERSISTENT_OVERFLOW,
PARTITION_REDUNDANT_PERSISTENT_OVERFLOW,
PARTITION_HEAP_LRU,
PARTITION_REDUNDANT_HEAP_LRU,
Going on to define the Region as <gfe:partitioned-region id="appData"
persistent="true"/> would immediately limit the available shortcuts to...
PARTITION_PERSISTENT,
PARTITION_REDUNDANT_PERSISTENT,
PARTITION_PERSISTENT_OVERFLOW,
PARTITION_REDUNDANT_PERSISTENT_OVERFLOW,
So, this is what David means by mutually exclusive attributes. See SGF-203 for more details.
Now, I realize Shortcuts define more than the Data Policy. They can define Eviction attributes,
Overflow and Expiration settings and so on. They are very convenient and something we should
consider, especially considering that SDG's more generic equivalent for client Regions (i.e.
<gfe:client-region .../>) supports Persistent, Data Policy, and Shortcut attributes.
However, care must be taken to define an order of precedence when a Shortcut is specified in
addition to the user overriding specific settings with a nested <gfe:eviction/> element, that
the appropriate settings are applied. David's ideas around bean definition inheritance will be
useful here.
Furthermore, consideration must be given to the Region's "scope" as well when Shortcuts are
used, so there is much to consider when thinking about the "shortcut" feature addition to be
sure.
Comment by John Blum [ 03/Mar/14 ]
Related JIRA tickets...
SGF-257 - strict XSD types on the peer Region 'data-policy' and 'shortcut' attributes.
SGF-258 - missing 'data-policy' attribute on <gfe:partitioned-region/>.
SGF-263 - 'disk-synchronous' attribute on Region bean definitions has no effect.
Comment by John Blum [ 21/Mar/14 ]
See GitHub PR #59 for more details.
Generated at Tue Feb 09 13:51:21 UTC 2016 using JIRA 6.4.11#64026sha1:78f6ec473a3f058bd5d6c30e9319c7ab376bdb9c.