In client/server mode, this is not the case, but should be. Doing correctly this will require a little more refactoring, repository file names are passed to the server on the command line. There must be some mechanism to passwords should probably be parsed from the repository files on instantiation. In retrospect, there are security implementations to passing passwords in a serialized PBKey via an ObjectStream. Since current behavior is not correct with respect to PBKeys in client/server, a password-less PBKey should be passed until the server is changed and security warning documentation added and/or optionally-encrypted streams implemented.
In sifting through the newest CVS version, I also noticed that GZIPped streams are now optional, but a change in Identity::serialize() is also required! I will send a patch for password-less PBKey, if that's what makes sense at this point -- and/or the Identity patch. I belive Identity can query the PersistenceBroker for the useCompression tag. Thanks, Corey -----Original Message----- From: [EMAIL PROTECTED] [mailto:hafman@;t-online.de] Sent: Tuesday, October 22, 2002 7:46 AM To: OJB Users List Subject: Re: PBKey and Pooling Hi Graham, ----- Original Message ----- From: "Graham Lounder" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Tuesday, October 22, 2002 1:29 PM Subject: PBKey and Pooling > Hey Guys and Gals, > > I got a question about PBKey. I'm writing a web application and I'm trying > to integrate it to another Oracle Web Application. In the Oracle App, each > user must log into the oracle database to use the app. Their username is > used in Triggers to keep track of actions in the database. > > I'd like to try the same thing by creating a PBKey for each user with their > username and password. Will this have any effect on the connection pooling? > I'm not sure if each PBKey has its own pool of connections or if there is > one connection pool with different connections uniquely identified by a > PBKey. This will end up in separate connection pools for each user (PBKey) and the specified user/password was used for connection access. Say you have a repositoryDB1.xml file with an jdbcConnectionDescriptor use a database DB1 and has user=u1, password=p1. Then you pass a PBKey (repositoryDB1.xml, u2, p2) this will instantiate a new DescriptorRepository/JdbcConnectionDescriptor based on repositoryDB1.xml with the passed user/password u2/p2 (override u1/p1 specified in repositoryDB1.xml). The JdbcConnectionDescriptor act as a key for the connection pooling, thus you will end up in separate pools. See DescriptorRepository#getInstance(PBKey pbKey) See DescriptorRepository#prepareJdbcConnectionDescriptor (PBKey key, JdbcConnectionDescriptor jcd) [Keep in mind, if you use the OJB internal tables (e.g H/L sequence manager) the default repository file (repository file specified in OJB.properties) needs a valid user/password.] HTH regards, Armin > > Any recommendations? > > Thanks in advance, > Graham > > ============================================ > Graham Lounder > Java Developer > Spatial Components Division > CARIS > 264 Rookwood Ave > Fredericton NB E3B-2M2 > Office 506 462-4263 > Fax 506 459-3849 > [EMAIL PROTECTED] > http://www.spatialcomponents.com > ============================================ > > > -- > To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org> > > > -- To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:ojb-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:ojb-user-help@;jakarta.apache.org>
