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 {
you can use a stupid one here too. just make sure it is sticky.
Tino Schwarze wrote:
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 replicatio
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 id;//sessi
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 r
Filip Hanik - Dev Lists wrote:
This byte based solution doesn't seem useful to me: for example in
JBoss there is support for finer grain replication, and it doesn't use
byte arrays.
I don't think data transfers get more fine grained than a single byte :)
Of course, but using byte[] as a type
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
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[] getSessionDi
Filip Hanik - Dev Lists wrote:
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() - optional, see is
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" a
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
comments inside
On 3/4/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
> 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
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 StandardS
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) configuring
thanks for the comments, replies inlined.
You may be able to simply judge isDiffable for yourself without that
method by checking that getSessionDiff() != null.
yes, that is true. I put in isDiffable, the semantics would be a little
easier to understand, than using a return value of null fo
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() -
14 matches
Mail list logo
