Enterprise Client Community

Hi Captain,

(I am using WorkplaceAPI)

Is it a good idea to store users database connection on Dispatcher ?

Thanks,
Vincent

Hi,

two answers:

1.

In principal the dispatcher is a central object within the objects on server side. So the idea to plug data there is 100% OK. Please pay attention, that in a workplace the dispatcher is hierarchized, so there is the most-outest dispatcher (top dispatcher) and there is a sub-dispatcher per workpage. - Each dispatcher has an owner (getOwner()), the sub-dispatchers return the top dispatcher, the top-dispatcher is returning null. - The top-dispatcher is created with a constructor without parameter, sub.dispatchers are created through the constructor.

2.

Is it a good idea to store connections? Normally not!... Connections should be active for a short point of time only (request enters system until response is given). It's a common pattern to avoid connections which span the duration of a user session. - Maybe you meant with "connection" a "connection provider", then it's OK.

ALTERNATIVE TO DISPATCHER:

An alternative to using the dispatcher is to use the "dialog session context on server side", which I would prefer to use. Example: the following stores the user-name in the central context:

Code:

 public class ViewContext
 {
     private static final String KEY = ViewContext.class.getName();
     
     private String m_userName;
     
     // ------------------------------------------------------------------------
     // constructors
     // ------------------------------------------------------------------------
 
     public static ViewContext instance()
     {
         ISessionAbstraction dialogSession = HttpSessionAccess.getCurrentDialogSession();
         ViewContext result = (ViewContext)dialogSession.getAttribute(KEY);
         if (result == null)
         {
             result = new ViewContext();
             dialogSession.setAttribute(KEY,result);
         }
         return result;
     }
 
     public String getUserName() { return m_userName; } 
     public void setUserName(String userName) { m_userName = userName; }    
     
 }

Why do I prefer this in front of the dispatcher?

You can extend the implementation of the instance() method to be also used from processing which is not part of the CaptainCasa request-response cycle. - Example: you may outsource certain operations into a separate thread (which then does not know about "dialog sessions"!). You can extend the instance() method e.g. by binding the ViewContext to the current thread - and still use it also from the processing within this thread.

Regards, Björn

Hi,

I am using pooled connection. So is connection provider == pooled connection ? If it is then I'm safe.

But definitely will try your alternative.

For now we are storing database connection on HttpSession which is really bad. So Im finding an alternative right now.

Hi,

@pooled connection: if you make sure that the connection is closed after each request/response then it's OK. But: without explicitly closing the connection, the pool does not help you ;-).

Björn

Hi,

Yes got it! Thanks for this.