Hi Oliver,
1. Where should I store the db-connection parameters. Now I have integrated it to service.xml! It works fine, but if I make the deployment of the services I generate an ".aar" file which includes also the service.xml. This implicates, that by updating the service on a server, the service.xml is also overwritten, it means the customer-settings (like db connection parameters, etc.) are lost and have to set again. Is there a better place to store such settings?
Do you really want to allow your customers to change DB connection parameters? This doesn't look like a very good decision.
Anyway, if they can change them, then you must put them somewhere outside the database, i.e. in file system. Since you overwrite .aar file each time you deploy your service you could use some other place in the file system.
2. I connect to db in the startUp method of an additional service-class implementing the ServiceLifeCycle interface and stores it to a service-parameter (the disconnecting is made in the shutDown method). So from the serveral service-methods I can acces the db-connection object over the servicecontext. It runs well. Now, my question is, was happens, if there comes several requests to services wich used the db-connection from different clients at the same time? I think there is only one db-connection object instance, so there can occur access violations, isn't it?
Yes. You could use locking to prevent this. Even better, you could add conncetion pooling to your application, plus, open the connection before writing to database, and close it afterwards. Connection is a valuable resource, and you shouldn't keep it open all the time.
Regards, Ognjen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
