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-14 19:47:58
|
Thomas:
When I read the source code, I am still confused about the relationship
about the management of jdbc connections. It seems like that the connection
is allocated based on the classdescriptor, though I am not sure how to
dedicate a JdbcConnectionDescriptor to a classdescriptor, but suppose it is
possible, I am still confused about the way jdbc connection is used.
Usually in web application, several users may access the same classes at
the same time, say updating a different article, and they should be handled
by different jdbc connection. But according to
ConnectionManager.getConnectionForClassDescriptor() method, it always return
the same connection for a single type of classes. So if two users are
accessing the article class at the same time, they will share the same
connection. That's what I am worried about.
Hope you can explain a litter bit more,
Best regards,
John W
----- Original Message -----
From: "Thomas Mahler" <tho...@ho...>
To: "John Wang" <hw...@re...>
Sent: Monday, March 11, 2002 10:38 PM
Subject: Re: [OJB-developers] About connection pool and preparedstatement
cache]
> Hi again John,
>
> John Wang wrote:
>
> > 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.
>
>
> Yes simply obtain a new PersistenceBroker to perform transactions in
> parallel. Use PersistenceBrokerFactory for this.
> It is important to release broker instances after use with
> PersistenceBrokerFactory.releaseInstance(broker).
>
> Of course it may also be a valid approach to serialize all user
> transactions. That is use just a single broker instance. Thus your app
> must wait for proccessing B until A's transaction is commited.
>
> hth,
>
> Thomas
>
>
> > 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >
> >
> >
> >
>
>
|
