Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Front Controller pattern and DataSource / Connection sharing

 
Ken Pelletier
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've been happily building/using my own basic framework based on the Front Contorller pattern with Command and Controller strategy.
For DB actions, a Connection, which is gotten from a DataSource (pooled connections) is handed to each command that a factory creates, called within the Controller's service method. This seems safe and efficient to me as the connection is used only by that command's invocation, and it's serviced by its own thread.
I've recently seen a similar Command/Controller framework a well-known book that actually creates a 'Connection' at servlet init time in the Controller and then passes that same Connection to each command.
My question is this: Isn't that approach non thread-safe? The controller servlet's Connection instance can't be safely shared by multiple service threads.
What's nagging at me is that it appears to be such and obvious, fundamental problem that I'm wondering if I'm just missing the point - not the author.
Any insights?
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18152
52
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Two words:
Connection Pool
 
John Carnell
Author
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ken Pelletier:
I've been happily building/using my own basic framework based on the Front Contorller pattern with Command and Controller strategy.
For DB actions, a Connection, which is gotten from a DataSource (pooled connections) is handed to each command that a factory creates, called within the Controller's service method. This seems safe and efficient to me as the connection is used only by that command's invocation, and it's serviced by its own thread.
I've recently seen a similar Command/Controller framework a well-known book that actually creates a 'Connection' at servlet init time in the Controller and then passes that same Connection to each command.
My question is this: Isn't that approach non thread-safe? The controller servlet's Connection instance can't be safely shared by multiple service threads.
What's nagging at me is that it appears to be such and obvious, fundamental problem that I'm wondering if I'm just missing the point - not the author.
Any insights?


This is not a very good thing. Any one of the threads in the servlet could close the connection even if another thread is using the connection. In addition, the transaction context in a non-J2EE environment is going to be tied to the connection. If one of the threads commits or rollsback on the connection all database transactions from that connection will commit or rollback.
Thanks,
John
 
John Carnell
Author
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim's comment is correct. If you are using a data source and connection pooling, you should not have any problems. However, if you are creating a connection directly (and not using connection pooling) in the init() and then passing that connection around to each incoming request, you are asking for problems.
Thanks,
John
 
Ken Pelletier
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi and thanks for the replies. I guess I wasn't as clear as I thought I was. (familiar refrain)
In my framework, I *am* using pooled connections, grabbing one per request, closing after. I'm happy that this is thread-safe, etc.
What this 'best practices' framework from the book does is create a 'Connection' instance from it's DataSource *at servlet init time*. ie: one Connection instance is held for the life of the FrontController servlet. That same connection instance is just getting passed into each Command. It gets closed at servlet destroy() time.
So, totally broken, right? That's what I thought, but I almost didn't believe it made it past editing, so I wondered if I was missing something there.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic