<div dir="ltr"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">> (When I last checked Infinispan, replication did only take</span><br style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">
<span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">>place each time you put an object into the map, but not on intermediate</span><br style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">
<span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">>changes to the object itself, and there was no replication of transient</span><br style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">
<span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">>fields; the same applies for Ehcache or Hazelcast.)</span><div><font color="#500050" face="arial, sans-serif"><br></font><div>Based on my reading, EhCache with BigMemory will keep the object consistent outside of cache management operations, which sounds (at least in theory) to provide more than Infinispan's solution. The transient field issue is one I know very little about in the context of distributed caching or the Shibboleth IDP, but it sounds like any replication solution based on (default) Java serialization would have issues adapting to transient fields. Is the expectation that transient fields would need to be replicated as long as a reference to the object exists outside the memcache? I probably need to dig into this more myself to understand why it's an issue and the role of the transient fields in the Shibboleth IDP.</div>
</div><div class="gmail_extra"><br><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">>I think I could easily adopt our Memcache plugin to support Infinispan,</span><br style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">
<span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">>Ehcache, Hazelcast or even JDBC or what you want, but due to the lack of</span><br style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">
<span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">>transient field persistence, it would never reach the same compatibility</span><br style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">
<span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">>as the Terracotta way.</span><br></div><div class="gmail_extra"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div class="gmail_extra" style>Understanding the "compatibility" issues or trade-off's, as in what will or won't work in the distributed environment might become key in our case. We have had some pressure to upgrade our solution to JDK 7. The better we understand issues we might face in extending the storage service, the better recommendation (ie "it can be done" or "it shouldn't be done") we can provide if JDK 7 becomes a more solid push by our client.<br>
</div></div>