concurrent execution of Statement's .addBatch() and .executeBatch()
Hello: Is it safe to call .addBatch() and .executeBatch() methods from multiple threads on the same PreparedStatement? Simple example: batching and executing a large number of the same statements (with the same PreparedStatement) by using ExecutorService. Thank you, Pavel. Jefferies archives and monitors outgoing and incoming e-mail. The contents of this email, including any attachments, are confidential to the ordinary user of the email address to which it was addressed. If you are not the addressee of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. This email may be produced at the request of regulators or in connection with civil litigation. Jefferies accepts no liability for any errors or omissions arising as a result of transmission. Use by other than intended recipients is prohibited. In the United Kingdom, Jefferies operates as Jefferies International Limited; registered in England: no. 1978621; registered office: Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. Jefferies International Limited is authorised and regulated by the Financial Services Authority.
Re: Vetting Derby. Technical documents?
> My company is evaluating whether to use Derby for a desktop/client-server > application where security and 21-CFR 11 compliance is important. Although Derby can be used perfectly well as a standalone database, it is also designed to be embedded into a containing application. The Derby libraries are small and stable, the memory footprint is predictable, and many other aspects of Derby favor this embedded usage. If you thus embed Derby into your application, you can arrange for little or none of the Derby APIs to be part of the exposed "surface" of your application, and therefore you can minimize your security exposure. For example, you say you are designing a client-server application; presumably Derby is to be part of the server component. But you do NOT need to make Derby be the *entire* server component. As an alternative design, you could implement your own completely locked-down web service, which provides just the APIs that your application client requires, in a highly-secure fashion, and embed Derby inside your secure web service. Hope these ideas give you some new perspectives to consider. thanks, bryan
