Thread: Re: [OJB-developers] About connection pool and preparedstatement cache]
Brought to you by:
thma
Menu
▾
▴
objectbridge-developers
|
From: John W. <hw...@re...> - 2002-03-11 18:35:32
|
I am thinking that in a web application development, usually we use a
connection pool, and get a connection from there. 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?
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?
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
>
|
|
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
> > >
> > >
> > >
> > >
> >
> >
>
|
|
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
>
>
>
>
|
|
From: Thomas M. <tho...@ho...> - 2002-03-11 19:48:14
|
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
>
>
>
>
|
|
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
> >
> >
> >
> >
>
>
>
|
|
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
> >
> >
> >
> >
>
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X