At a first glace Java serialization is needed because of its awareness of the reference graph. But in the same time it does not perform well. One way might be the byte level instrumentation that would induce code to figure out the reference graph and know how to stream-ify it using a given efficient protocol. But that induces risks and it involves tons of work. I think would be doable though.
The problem is not really the technology of propagating session information to other nodes. That's the easiest part, but tough one is figuring out the low level reference graph and serialization semantics. This is why JINI, JavaSpaces, JGroups, CORBA, JXTA, you name it, are unlikely to help solving the fundamental problem. Br's, Marius On Aug 23, 8:16 pm, Arthur <[email protected]> wrote: > On Sun, Aug 23, 2009 at 7:04 PM, David > > Pollak<[email protected]> wrote: > > On Sun, Aug 23, 2009 at 4:50 AM, Kevin Wright > > <[email protected]> wrote: > > >> I'm wondering if we can't leverage JavaSpaces to handle a lot of this > >> stuff. From my experience with the technology it seems to be a pretty good > >> fit for the problem. > > > Two reasons: > > - JavaSpaces is as far as I know, GPL and we will not mix any GPL into Lift > > JavaSpaces is just the specification. There are two implementations I > know of: BlitzJavaSpaces (BSD) and GigaSpaces (proprietary?). I don't > have hands on experience with either. > > > - It doesn't solve the issue with low-level session replication which relies > > on serialization of the session data for transfer to another app server > > instance. > > Arthur --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
