Ulf Dittmer wrote:
I guess I don't know how to properly use databases with rest. I forward to the servlet so database updates can be made.
I think this goes to the heart of the matter. Why do you think using a DB with a REST APi would be any different than using a DB with a servlet?
Ulf Dittmer wrote:I guess I don't understand why there are servlets at all. Unless they are also used for some web app that emits HTML to browsers and needs to use the same logic (in which I would still say the approach I outlined in my previous post is a better design), using servlets seems a complication that doesn't add value. Am I missing something?
Marshall Blythe wrote:
Greg Bag wrote:So is this personDaoImpl thread-safe? If I was to use a single instance variable in the servlet, that wouldn't pose an issue? What if 1000 requests call createPerson at the same time on the same instance of PersonDaoImpl?
It's thread-safe, but you need to consider using the connection pooling features of your DataSource if your servlet is going to be handling hundreds of concurrent requests. The connection pool is usually administered in the JEE container and is transparent to the client application. Check your JDBC driver and JEE container documentation to see how to setup a connection pool.
E Armitage wrote:First, I would make the createPerson method return something that tells me if the create was successful or not and I wouldn't just hide the exception with that catch block.
You should be fine with regards to concurrency because you are not keeping state in your servlets and you are not keeping a connection as an instance variable. Generally when it comes to connections you should get one when you need it (in the method that needs it) and close it soon after using it.
Sresh Rangi wrote:In one of these example, there are mutations to the object after the final variable is set. I don't think they are guaranteed to be visible. Consider two examples:
In example 1, the set is mutated after the instance variable is set. We have actions:
a) Thread1: - mySet initialization
b) Thread1: - set add
c) Thread2: - set contains
The happens-before relationships are: hb(a, b) and hb(a, c). This allows the orderings a -> b -> c and a -> c -> b.
In example 2, the set is mutated before the instance variable is set. We have actions:
a) Thread1: a - set add
b) Thread1: b - mySet initialization
c) Thread2: c - set contains
The happens-before relationships are: hb(a, b) and hb(b, c). This only allows a -> b -> c.
So reading a final variable only guarantees visibility of actions that happen before it's set.