Re: [OJB-developers] About connection pool and preparedstatement cache]
Brought to you by:
thma
Menu
▾
▴
Re: [OJB-developers] About connection pool and preparedstatement cache]
|
From: John W. <hw...@re...> - 2002-03-11 20:32:15
|
Thanks for your response.
>. If you are
> running a servlet engine and your machine is powerful enough the best
> thing is to run OJB within the same VM as the servlet engine.
I agree with you. I am just wondering how to support multiple concurrent
requests in the servlet engine. Say user A's request comes in, the servlet
will use the PersistenceBrokerImpl and its connection, before the servlet
finishes this request and commit his changes, user B's request comes in,
should he create a new PersistenceBrokerImpl and a new connection? I assume
that he can't use the same PersistenceBrokerImpl and the connection with
User A, because user A hasn't committed the changes yet.
Hope it is clear,
thanks again,
John W
----- Original Message -----
From: "Thomas Mahler" <tho...@ho...>
To: "John Wang" <hw...@re...>
Cc: <obj...@li...>
Sent: Monday, March 11, 2002 11:35 AM
Subject: Re: [OJB-developers] About connection pool and preparedstatement
cache]
> Hi again John
>
> John Wang wrote:
>
> > I am thinking that in a web application development, usually we use a
> > connection pool, and get a connection from there.
>
>
> OK
>
> > So in the app server, say
> > tomcat, need to maintain a pool of connections(I guess we should use
> > PersistenceBrokerImpl for OJB), and use app server's load balancer and
> > JOB's
> > distributed cache to improve the performance and workload. I am very
> > concerned about the performance of OJB's C/S mode and other network
calle
> > mechanisms(like ejb), I am thinking that this may be a better approach.
Do
> > you agree with me?
>
>
> I'm not sure if I got you right. But I give it a try:
> The OJB way of working with PreparedStatements is to cache them for
> maximum performance. To keep a PreparedStatement hot the underlying Jdbc
> Connection must be active.
> Thus if you return the connection object used by the OJB broker to the
> app servers pool OJBs caching of PreparedStatements would be superfluous.
>
> Before re-using a PreparedStatement OJB checks if the connection is
> still alive.
> Thus it is totally safe to release the Connection object to the app
> servers pool.
>
> Feel free to do this! But imho it will have a negative performance impact.
>
> I don't understand why you bring in the OJB C/S mode here. If you are
> running a servlet engine and your machine is powerful enough the best
> thing is to run OJB within the same VM as the servlet engine.
>
> If you are forced to scale, that is run Servlet Engine and OJB on
> multiple machines you must use the OJB C/S mode.
>
> Don't make things to complicated!
>
>
> > So the problem is that, when you try to retrieve a connection, it
should
> > return an available one from the pool, instead of a fixed one. Has
anyone
> > done such an example?
> > And so, if the connection retrieved is dynamic, how to enable the cache
of
> > perparedstatement?
>
>
> As I told you before: The OJB PreparedStatement cache will check if the
> underlying connections are still valid. Just release your connections to
> the ConnectionPool if you feel like. OJB will do the rest.
>
> BUT: please don't complain when performance goes down !!!
>
>
> HTH,
>
> Thomas
>
>
> > Thanks a lot,
> > John W
> >
> >
> >>----- Original Message -----
> >>From: "Thomas Mahler" <tho...@ho...>
> >>To: "ojb" <obj...@li...>
> >>Sent: Saturday, March 09, 2002 3:10 AM
> >>Subject: [Fwd: Re: [OJB-developers] About connection pool and
> >>preparedstatement cache]
> >>
> >>
> >>
> >>>John Wang wrote:
> >>>
> >>> > I noticed that for a class, it can only use the same connection,
> >>>even for
> >>> > different users. So when 2 users are accessing the same class
> >>>objects, they
> >>> > will share the same connection, and may cause some problem, right?
> >>> >
> >>>
> >>>
> >>>Why should this be problematic? a PersistenceBroker handles only one
> >>>JDBC transaction at a time. If two threads (or users) are working with
> >>>the the same broker only one of them can perform transactional
> >>>operations at a time.
> >>>
> >>>If two threads (or users) need to work in parallel they have to obtain
> >>>individual PersistenceBrokers. As each PersistenceBroker holds its own
> >>>Connections there is again no problem here.
> >>>
> >>>What kind of problems are you thinking of?
> >>>
> >>>
> >>> > In ConnectionManager.getConnectionForClassDescriptor, it will get
> >>>
> > from
> >
> >>> > hashmap, so it will return the same for a classdescriptor.
> >>> >
> >>>
> >>>
> >>>Yes, per broker it's possible to have a dedicated Connection for each
> >>>persistent Class. but in general all classes share a default
connection.
> >>>
> >>>
> >>> > The preparedstatement is also cached in the StatementsforClass,
which
> >>>
> >>is
> >>
> >>> > good. I am just wondering whether it can live outside of a
> >>>
> > connection.
> >
> >>> >
> >>>
> >>>
> >>>
> >>>PreparedStatements depend on a active Connection. Thus before using a
> >>>cached PreparedStatement OJB always checks if the Connection is still
> >>>
> >>alive.
> >>
> >>>HTH,
> >>>
> >>>Thomas
> >>>
> >>>
> >>> > Thanks a lot,
> >>> > John W
> >>> >
> >>> >
> >>> > ----- Original Message -----
> >>> > From: "Georg Schneider" <ge...@me...>
> >>> > To: <obj...@li...>
> >>> > Sent: Friday, March 08, 2002 1:33 AM
> >>> > Subject: [OJB-developers] dynamic proxies
> >>> >
> >>> >
> >>> >
> >>> >>Hi,
> >>> >>
> >>> >>I just implemented a few lines to enable dynamic proxies to also
> >>>implement
> >>> >>interfaces which are implemented by classes further up the
> >>>
> > inheritance
> >
> >>> >>hierarchy. I just added the following lines in RepositoryXmlHandler
> >>>in the
> >>> >>method getDynamicProxyClass:
> >>> >>
> >>> >> Class[] interfaces = clazz.getInterfaces();
> >>> >> //added from here on
> >>> >> Class superClass = clazz;
> >>> >>
> >>> >> while((superClass = superClass.getSuperclass()) != null) {
> >>> >>
> >>> >>Class[] superInterfaces = superClass.getInterfaces();
> >>> >>
> >>> >>Class[] combInterfaces =
> >>> >> new Class[interfaces.length +
> >>> >> superInterfaces.length];
> >>> >>System.arraycopy(interfaces,0,combInterfaces,0,
> >>> >>interfaces.length);
> >>> >>System.arraycopy(superInterfaces,0,combInterfaces,
> >>> >>interfaces.length,
> >>> >>superInterfaces.length);
> >>> >>interfaces = combInterfaces;
> >>> >> }
> >>> >> //end added
> >>> >>
> >>> >> Class proxyClass = Proxy.getProxyClass(
> >>> >> clazz.getClassLoader(), interfaces);
> >>> >>
> >>> >>
> >>> >>Regards
> >>> >>
> >>> >>Georg
> >>> >>
> >>> >>
> >>> >>_______________________________________________
> >>> >>Objectbridge-developers mailing list
> >>> >>Obj...@li...
> >>> >>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >>> >>
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > Objectbridge-developers mailing list
> >>> > Obj...@li...
> >>> > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >>> >
> >>> >
> >>> >
> >>> >
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>Objectbridge-developers mailing list
> >>>Obj...@li...
> >>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >>>
> >
> >
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >
> >
> >
> >
>
>
>
|
