While we're on the subject I'd like to comment since I actually use UUID's. I
use them to keep track of users who have logged in. AFAIK
maintainSession(true) doesn't work with multiple services. I'd like to use
ServiceGroupContext and WS-Addressing to do this. Yet it seems harder then it
should be and not many people are using it yet.
The way I use UUID's is to have a service login(), which returns a UUID via a
complex object. Every service call by that client thereafter passes in the
UUID. I use java.util.UUID inside the service, although I could just as
easily use commons-id.
My whole point here is:
1) AFAICT since a UUID via a messageContext isn't available to the user of the
client Stub directly via a public method, I'd have to implement a handler to
access it.
2) There's no associated timeout state with the UUID.
3) I'm reinventing the wheel and not utilizing the UUIDGenerator already being
used. Yet the solution I'm using is common and is often discussed on the user
list.
4) Using mc.setIDGenerator() is doesn't seem any easier than just doing it
myself as described above.
A few Simple questions then: Can the MessageContext UUID be used to control
login state and timeout? Can the implementation be pluggable, ie I want a
type 4 UUID? And finally is the only way to control the MessageContext UUID
is via a handler?
iksrazal
Em Sexta 16 Dezembro 2005 15:31, o Glen Daniels escreveu:
> Hi Sanjiva:
> > Is there any reason why we can't make it so that every message context
> > has an id when its created? I'm fine with having getId() and setId() so
> > that the default ID can be changed but it seems to me that we never use
> > a message context without setting the ID. This avoids repeated code
> > fragments like:
> >
> > if (msgctx.getMessageID() == null) {
> > String messageID = String.valueOf("uuid:" + UUIDGenerator.getUUID());
> > msgctx.setMessageID(messageID);
> > }
>
> I'm not sure every MC really needs an ID - for instance, if you're doing
> sync req-resp over HTTP (quite a common case these days), you don't need
> IDs for correlation at all, since you can just keep the objects
> associated with the thread/socket.
>
> For the cases where we do need an ID, I'd like to avoid UUID generation
> unless necessary (even cheap versions are lots more expensive than
> simpler ID schemes). How about this:
>
> interface IDGenerator {
> String getID();
> }
>
> class SimpleIDGen implements IDGenerator {
> static SimpleIDGen singleton() {
> // get singleton
> }
>
> static long curMaxID = 0;
> String getID() {
> // return simple autoincrementing long
> synchronized (singleton) {
> return Long.toString(curMaxID++);
> }
> }
> }
>
> class MessageContext {
> String messageID;
> IDGenerator idGen = SimpleIDGen.singleton();
>
> String getMessageID() {
> if (messageID == null) {
> messageID = idGen.getID();
> }
> return messageID;
> }
> }
>
> That way, we get usable auto-incrementing IDs by default, delivered only
> on demand, unless someone calls mc.setIDGenerator() with a UUID-based one.
>
> Thoughts?
>
> --Glen
