Andy Piper wrote:
Hi Filip
At 04:44 PM 3/3/2006, Filip Hanik - Dev Lists wrote:
3. And the key to this, is that we will have an implementation of a
LazyReplicatedHashMap
The key object in this map is the session Id.
The map entry object is an object that looks like this
ReplicatedEntry {
Hi Filip
At 04:44 PM 3/3/2006, Filip Hanik - Dev Lists wrote:
3. And the key to this, is that we will have an implementation of a
LazyReplicatedHashMap
The key object in this map is the session Id.
The map entry object is an object that looks like this
ReplicatedEntry {
string
Hi Filip,
On Fri, Mar 03, 2006 at 10:44:21AM -0600, Filip Hanik - Dev Lists wrote:
I wrote together a little idea (also emailed to geronimo-dev for
feedback) on how the next generation of session replication should be done.
Today's replication is an all-to-all replication, and within that
I wrote together a little idea (also emailed to geronimo-dev for
feedback) on how the next generation of session replication should be done.
Today's replication is an all-to-all replication, and within that realm,
its pretty poor. It creates way to much network traffic as each request
results
Hola,
A couple of small comments:
1. Requirements to be implemented by the Session.java API
bool isDirty - (has the session changed in this request)
bool isDiffable - is the session able provide a diff
byte[] getSessionData() - returns the whole session
byte[] getSessionDiff() -
Hello Filip,
very interesting proporsal indeed. May I point you to some importand
use-cases and ask whether your proporsal has solutions for it.
1. Poviding an easy way to customize diffs.
As far as I understand customizable diffs are possible by a) patching
the StandardSession or b)
Leon Rosenberg wrote:
Hello Filip,
very interesting proporsal indeed. May I point you to some importand
use-cases and ask whether your proporsal has solutions for it.
1. Poviding an easy way to customize diffs.
As far as I understand customizable diffs are possible by a) patching
the
ups:
If we would store the result-set (list of already created beans) in
the session,
read:
If we would _NOT_ store the result-set (list of already created beans) in
the session,
Sorry.
Leon
-
To unsubscribe, e-mail: [EMAIL
for very large clusters, you use the same mechanism, except, instead of
distributing the entire session map, the backup node info is stored in a
cookie.
Filip
If we would store the result-set (list of already created beans) in
the session, we'd have to store them twice, once in the cache
