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 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
>
|
