Kathey Marsden wrote:
David Van Couvering wrote:
Hi, all. I have had some further thought on this, and I have a proposal. It seems like how one generates ids depends upon the environment Derby is running in. In a single-VM environment, probably the hashCode() solution is best because it works even if there are multiple systems in the same VM. However, in a clustered environment, a UUID is probably required. So I am proposing creating a new service, ObjectIdGenerator. This allows us to plug in a different implementation at some future date if need be.
I have to admit my feeble eyes are disappointed at the loss of the
counter and I don't really get how you separate out some things like
the error logs in these multiple jvm systems , but any additional help
in differentiating connections would be welcome so hashcodes, counters, UUID's, all fine with me.
Yes, I agree, but it would be a real pain if you got the same id twice! And with hashCode, you can avoid the need for specifying the class name as part of the id, as hashCode is unique across classes.
I am assuming the ObjectIdGenerator is just an engine side service? Right now the only shared classes between the engine and client are the
product version and sysinfo classes. If classes that are likely to
change get included in both jars it could be ugly and with mismatched
clients and servers you would get different implementations depending on
what came first in your classpath.
Hi, Kathey, you have a good point about the ObjectIdGenerator being shared. I would like to understand our goal for sharing code across network client and server. It sounds like right now there is no sharing and if you have similar functionality it must be duplicated. Isn't there any way to fix this? Could we have a derbyutils.jar or derbycore.jar or something like that which is shared between both client and server code, where common services like this can go?
Also, don't we have the need for pluggable services (security, logging, etc.) on the network client side? Shouldn't we have some model like the server-side module/service model for the network client code?
In the meantime, I think what I'll do is just use the identityHashCode() for the network-client connection ids. If and when we agree on an approach I can (or someone else can) adjust this in the future
Another thing that would be very nice is if, in client/server mode, client connection toString() has a correlation to the resulting embedded connection toString() created on the server side for that session. This way you could get end-to-end correlation.
This maybe could be done by fixing Derby-17, Network Server Needs to generate CRRTKN on ACCRDB if client does not send it. The protocol has a pretty specific format which perhaps would be helpful for your embedded format as well except it does include the network address, so you would have to look at it more closely to see.
I'll add some comments to Derby-17 with some more information.
OK. I'd like to suggest this is a separate item, and doesn't need to be resolved with this patch, do you agree?
Thanks,
David
What an adventure!
Kathey
