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. 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. >> 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. What an adventure! Kathey
