When not using EJBs can I make BD a Singleton and cache facade instances?
Hi,
In an application which does not use EJBs can I make BD(Business Delegate) a singleton?
I was very sure about doing this but when I tried Google on the same subject the answers were'nt supportive of this but that was in the context of applications which used EJBs. And also item 4 in Effective Java isnt very supportive of caching Objects at the drop of a hat.
When not using EJBs would it be an unnecessary thing to make BD a singleton and cahce Facade instances in a BD and DAO instances in a Facade? I am planning to use a array based blocking bounded buffer for the purposes of caching. Or would it be better to make both BD and a facade as SIngletons and just cache DAOs in a Facade?
Any suggestion would be of good help to me.
Thanks a lot.
[788 byte] By [
Amnesiaca] at [2007-10-2 11:09:37]
> In an application which does not use EJBs can I make> BD(Business Delegate) a singleton?Singleton means a single instance.EJBs means J2EE which means threads.So how are you going to handle threading issues in that single instance?
> Singleton means a single instance.
> EJBs means J2EE which means threads.
>
> So how are you going to handle threading issues in
> that single instance?
Right now I do not see having any instance variables in a BD other than the facade. I am also aware of the threading issues due to Objects being leaked out from the ownership domain and I dont see doing that either. So if there is any threading issue it has to be with regard to the access of the facade instance.
If I make the facade a Singleton, there will be DAOs as intance variables to which I need to synchronize access. Otherwise, if I dont make the facade as a Singleton I plan to have a array based bounded buffer which will block and hence have synchronization at the appropriate places, same with the DAOs which will be cached in the same way as facades.
Thank you for the reply.
Not sure I understand all your design, but you seem to describe an architecture where requests are queued and handled serially.
The impact on throughput of handling requests serially (as opposed to parallelizing them) probably outweights by far the cost of instantiating one more object per request...
> > Singleton means a single instance.
> > EJBs means J2EE which means threads.
> >
> > So how are you going to handle threading issues in
> > that single instance?
>
> Right now I do not see having any instance variables
> in a BD other than the facade. I am also aware of the
> threading issues due to Objects being leaked out from
> the ownership domain and I dont see doing that
> either. So if there is any threading issue it has to
> be with regard to the access of the facade instance.
>
> If I make the facade a Singleton, there will be DAOs
> as intance variables to which I need to synchronize
> access. Otherwise, if I dont make the facade as a
> Singleton I plan to have a array based bounded buffer
> which will block and hence have synchronization at
> the appropriate places, same with the DAOs which will
> be cached in the same way as facades.
>
If you attempt to use a single connection in multiple threads there could be issues depending on the database/driver.
If you attempt to use a single statement/resultset in multiple threads then there will be problems.
> Not sure I understand all your design, but you seem
> to describe an architecture where requests are queued
> and handled serially.
Sorry if I messed up while explaining it. No, it will not be handled serially. Since the BD is a singleton multiple threads can pass messages to it simulteanously, a bit like an object of the Action class in Struts. Since I dont see having any synchronized methods in a BD requests will be handled simulteanously.
> The impact on throughput of handling requests
> serially (as opposed to parallelizing them) probably
> outweights by far the cost of instantiating one more
> object per request...
Yes, I understand that but as I explained above the reqests wont be handled serially.
To be more clear, I am thinking of using any one of these two things:
1) BD(Singleton)-->Facade(Singleton, caches DAOs in a thread safe data structure)
2)1) BD(Singleton, caches Facade instances in a thread safe data structure)-->Facade(caches DAOs in a thread safe data structure).
the thread safe data structure I am planning to have is a array based bounded buffer which blocks using wait and notify mechanism.
Thank you for the reply.
> If you attempt to use a single connection in multiple
> threads there could be issues depending on the
> database/driver.
A connection Object will be a local variable and it will not be leaked outside the method in which it is created. Thank you for this, I'll look if there can be any problems. You've made me think about having a Connection object as a local variable is really a good thing or should I do something else like one connection per transaction or per unit of work. If I want to make it per unit of work(something like per use-case) I can acheive it by retreiving connections in a facade rather than a DAO but I guess that is a bad practise.
> If you attempt to use a single statement/resultset in
> multiple threads then there will be problems.
I am using a Transfer Object which is generated in the DAO and passed around. I may also use a RowSet if needed. Each Thread will have its own Connection Object so I dont think the ResultSet or Statement Object will be shared.
Thank you for the reply.
> > If you attempt to use a single connection in
> multiple
> > threads there could be issues depending on the
> > database/driver.
>
> A connection Object will be a local variable and it
> will not be leaked outside the method in which it is
> created.
That statement is inconsistent with the concept of a Singleton.
A Singleton represents a single instance.
Your comments suggest that you are just creating a helper class.
> Thank you for this, I'll look if there can
> be any problems. You've made me think about having a
> Connection object as a local variable is really a
> good thing or should I do something else like one
> connection per transaction or per unit of work. If I
> want to make it per unit of work(something like per
> use-case) I can acheive it by retreiving connections
> in a facade rather than a DAO but I guess that is a
> bad practise.
>
Connection pools are a pretty standard feature in the world of programming.
