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 22:45:31
|
Well, sorry for my midunderstanding before, I think the connectionmanager
belongs the persistencebroker, so if several users comes in, they use the
different persistencebroker, thus use different connectionmanager and jdbc
connection.
How to specify a type of JDBC connection for a class descriptor in
configuration file? Usually it used the "default" one, right?
thankx,
John W
----- Original Message -----
From: "John Wang" <hw...@re...>
To: <obj...@li...>
Sent: Thursday, March 14, 2002 11:52 AM
Subject: Re: [OJB-developers] About connection pool and preparedstatement
cache]
> 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
> > >
> > >
> > >
> > >
> >
> >
>
|
