From derby-dev-return-3967-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Tue May 10 00:21:11 2005 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 32928 invoked from network); 10 May 2005 00:21:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 May 2005 00:21:10 -0000 Received: (qmail 98605 invoked by uid 500); 10 May 2005 00:24:29 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 98578 invoked by uid 500); 10 May 2005 00:24:29 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Development" Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 98517 invoked by uid 99); 10 May 2005 00:24:29 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from e3.ny.us.ibm.com (HELO e3.ny.us.ibm.com) (32.97.182.143) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 09 May 2005 17:24:28 -0700 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4A0L3eu018604 for ; Mon, 9 May 2005 20:21:03 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4A0L3w0108534 for ; Mon, 9 May 2005 20:21:03 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4A0L3Xc007362 for ; Mon, 9 May 2005 20:21:03 -0400 Received: from [127.0.0.1] (sig-9-48-117-120.mts.ibm.com [9.48.117.120]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4A0L0DL007236 for ; Mon, 9 May 2005 20:21:02 -0400 Message-ID: <427FFE6B.2040404@sbcglobal.net> Date: Mon, 09 May 2005 17:20:59 -0700 From: Kathey Marsden User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derby Development Subject: Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection References: <44794879.1115418005121.JavaMail.jira@ajax.apache.org> <427BF4D8.1090904@debrunners.com> <427C0881.3090600@sun.com> <427FCFB7.8030501@sun.com> In-Reply-To: <427FCFB7.8030501@sun.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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