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: Thomas M. <tho...@ho...> - 2002-03-15 06:40:48
|
Hi John,
John Wang wrote:
> 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.
Exactly! That was the point I tried to explain in my previous mails.
Users usually won't work directly with Connections.
> How to specify a type of JDBC connection for a class descriptor in
> configuration file? Usually it used the "default" one, right?
> thankx,
If you have a look at the repository.dtd you will see that the
Repository must contain a default JdbcConnectionDescriptor right at the
beginning of the repository.
But the definition for the ClassDescriptor element also contains an
optional JdbcConnectionDescriptor element. Thus it is possible to place
a JdbcConnectionDescriptor at the beginning of a ClassDescriptor like
follows:
<ClassDescriptor id="1">
<JdbcConnectionDescriptor id="default">
<dbms.name>Hsqldb</dbms.name>
<driver.name>org.hsqldb.jdbcDriver</driver.name>
<url.protocol>jdbc</url.protocol>
<url.subprotocol>hsqldb</url.subprotocol>
<url.dbalias>../OJB</url.dbalias>
<user.name>sa</user.name>
<user.passwd></user.passwd>
</JdbcConnectionDescriptor>
<class.name>test.ojb.broker.Article</class.name>
<class.proxy>dynamic</class.proxy>
<class.extent>test.ojb.broker.BookArticle</class.extent>
<class.extent>test.ojb.broker.CdArticle</class.extent>
<table.name>Artikel</table.name>
...
</ClassDescriptor>
HTH,
Thomas
> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
>
>
>
|
