javtools-poolmngr — Architecture discussion regarding the db pool manager

[Javtools-poolmngr] Letter

[..... <aaa...@ne...>]

Dear friend

With regards and honor do please consider this proposal.I am from Zimbabwe but currently i and my brother is in Netherland.You might be worried how i got your contact address, I got it from Chamber of Commerce and trade e-mail directory.

Dear friend during this crises against the farmers of Zimbabwe by the supporters of our President Robert Mugabe to claim all the white owned farms in our country, he ordered all the white farmers to surrender their farms to his party members and their followers

My father was one of the best farmers in the country and knowing that he did not support the presidents political ideology, the presidents supporters invaded my fathers farm burnt down everything, shot him and as a result of the wounds sustained, he became sick and died after four days.And after his death,I and my younger Brother decided to move out of Zimbabwe for the safety of our lives to South-Africa.from thier we where able to enter into a 
ship and travel to the Netherland.

But, before he died he wrote his will, which reads (MY BELOVEED SON ,I WISH TO DRAW YOUR ATTENTION TO THE SUM OF ($7.5,000000). MILLION U.S DOLLARS WHICH I DEPOSITED IN A SECURITY COMPANY IN JOHANNESBURG (SOUTH-AFRICA)and i have ask them to transfer it to thier branch in the netherland and secured it.IN CASE OF MY ABSENCE ON EARTH CAUSED BY DEATH ONLY".You should solicit for reliable foreign partner to assist you to transfer this money out of netherland for investment purpose.

I deposited the money in your name and it can be claimed by you alone with the deposite code. your mother has all the documents.Take good care of your mother and brother."

From the above, you will understand that the lives and future of my family depends on this money as much, I will be grateful if you can assist us.I and my younger brother are now living in the Netherland as POLITICAL ASYLUM SEEKERS and the financial law of the Netherland does not allow ASYLUM SEEKERS certain financial rights to such huge amount of money .

In view of this, I cannot invest this money in the Netrherland,hence I am asking you to assist me transfer this money out of Netherland and secure it for investment purposes. 

For your efforts, I am prepared to offer you 10% of the total fund, while 2% will be set aside for local and international expenses and 88% will be kept for me and my family.

Finally modalities on how the transfer will be done will be conveyed to you once we establish trust and confidence between ourselves. Looking forward to hear from you For more detailed information. 

NOTE:THE KEY WORD TO THIS TRANSACTION IS ABSOLUTE CONFIDENTIALITY AND SECRECY.THIS TRANSACTION IS 100% RISK FREE. YOUR URGENT RESPONSE WILL BE HIGHLY APPRECIATED.

BEST REGARDS,

[Javtools-poolmngr] Contact Info

[Isabelle M. <isa...@pr...>]

Hi everyone,

Since I was the only one without an ICQ id, I've given in :-)

My ID : 166393202


isabelle
-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Get 4 DVDs for $.49 cents! plus shipping & processing. Click to join. 
http://adfarm.mediaplex.com/ad/ck/990-1736-3566-59

Re: [Javtools-poolmngr] Suggested course of action

[Isabelle M. <met...@pa...>]

Hi everyone,

I suggest everybody go have a look at the subproject discussion forum, topic
"Xsql additions". I'm not going to repeat everything here in detail, but
here's what it boils down to :

(1) We build a generic SQL facility which allows a developer to send a batch
of DML commands (select, update, insert, delete) to a bean. The request and
response are both XML.
(2) The bean uses the pool manager for obtaining a connection and submits
the statements to the database and collects the results.

So, the pool manager is just that, and the other aspects Stefaan is
interested in are bundled into the GenSQL bean.

The main advantage is separation of concerns : the pool and the SQL facility
are independent.

Isabelle


----- Original Message -----
From: "Stefaan Delanghe" <st...@ya...>
To: "Isabelle Muszynski" <met...@pa...>
Cc: <Jav...@li...>
Sent: Saturday, August 03, 2002 10:12 AM
Subject: Re: [Javtools-poolmngr] Suggested course of action


> Hi,
>
> I agree on the all of these requirements.
> But I have some suggestions to make:
> 1) Would it not be better to encapsulate the connection object and provide
a type
> shell to execute statements.
> 2) On bases of the number 1 we could also provide a transaction mechanism.
(Execute
> several statements at ones).
>
> 3) Another possible solution is to implement the requirments as described
by
> Isabelle and later on provide a database shell (A easy to use class for
the user to
> request actions on the database).
>
>
> Stefaan
>
> --- Isabelle Muszynski <met...@pa...> wrote:
> > Personally, I think that for the first release the requirements should
be :
> >
> > (1) provide pooled connections to users
> > (2) the connections in one pool can be either all the same type of JDBC
> > connection (same connection URL, username/password) or they can be
different
> > type. An other alternative would be to have more than one pool, and each
> > pool is homogeneous.
> > (3) the user protocol is : borrow, use, return.
> > (4) we can set some policies as to how long a connection may be in use
> > (difficult in real life, because a very busy servlet might hold on to
the
> > connection for a long time)
> > (5) the pool is self-regulating : grows when connection demand is
intensive,
> > shrinks when less demand
> > (6) configuration thru XML config file
> >
> > IMO these are sufficient for a first release.
> >
> > isabelle
> >
> > ----- Original Message -----
> > From: "Amit Deshpande" <ami...@ra...>
> > To: "PoolManager (E-mail)" <Jav...@li...>
> > Sent: Friday, August 02, 2002 8:24 AM
> > Subject: [Javtools-poolmngr] Suggested course of action
> >
> >
> > > Hi All,
> > >          Suddenly there's a lull ...
> > > anyway how about getting the requirements from a user point of view
listed
> > > first,
> > > we already have a few requirements listed.
> > > We could have a look ta some existing pool managers  and jot down some
> > > features which are missing and are desired.
> > > We could then freeze the requirements.Lets not mix the technical
> > discussions
> > > with these.
> > >        As far as the technical discussions like server crash,chunking
etc
> > > are concerned lets get to tackle those after the requiremenst are
> > over.These
> > > are internal implenentations transparent from an end user point of
view
> > and
> > > implemented to enhance performnace of the pool-manager.So we could
after
> > the
> > > requirements phase list some critical issues like performance
> > > enhancers,bottlenecks,configuration methods ,scalability mechanisms
and
> > > could have  a detailed discussio on those before proceeding to the
design
> > > phase.
> > >      I need your comments on these, esp Isabelle.
> > > - Amit
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Javtools-poolmngr mailing list
> > > Jav...@li...
> > > https://lists.sourceforge.net/lists/listinfo/javtools-poolmngr
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Javtools-poolmngr mailing list
> > Jav...@li...
> > https://lists.sourceforge.net/lists/listinfo/javtools-poolmngr
>
>
> =====
> Stefaan Delanghe
> ICQ: 110055343
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>

Re: [Javtools-poolmngr] Suggested course of action

[Stefaan D. <st...@ya...>]

Hi,

I agree on the all of these requirements.
But I have some suggestions to make:
1) Would it not be better to encapsulate the connection object and provide a type
shell to execute statements.
2) On bases of the number 1 we could also provide a transaction mechanism. (Execute
several statements at ones).

3) Another possible solution is to implement the requirments as described by
Isabelle and later on provide a database shell (A easy to use class for the user to
request actions on the database).


Stefaan

--- Isabelle Muszynski <met...@pa...> wrote:
> Personally, I think that for the first release the requirements should be :
> 
> (1) provide pooled connections to users
> (2) the connections in one pool can be either all the same type of JDBC
> connection (same connection URL, username/password) or they can be different
> type. An other alternative would be to have more than one pool, and each
> pool is homogeneous.
> (3) the user protocol is : borrow, use, return.
> (4) we can set some policies as to how long a connection may be in use
> (difficult in real life, because a very busy servlet might hold on to the
> connection for a long time)
> (5) the pool is self-regulating : grows when connection demand is intensive,
> shrinks when less demand
> (6) configuration thru XML config file
> 
> IMO these are sufficient for a first release.
> 
> isabelle
> 
> ----- Original Message -----
> From: "Amit Deshpande" <ami...@ra...>
> To: "PoolManager (E-mail)" <Jav...@li...>
> Sent: Friday, August 02, 2002 8:24 AM
> Subject: [Javtools-poolmngr] Suggested course of action
> 
> 
> > Hi All,
> >          Suddenly there's a lull ...
> > anyway how about getting the requirements from a user point of view listed
> > first,
> > we already have a few requirements listed.
> > We could have a look ta some existing pool managers  and jot down some
> > features which are missing and are desired.
> > We could then freeze the requirements.Lets not mix the technical
> discussions
> > with these.
> >        As far as the technical discussions like server crash,chunking etc
> > are concerned lets get to tackle those after the requiremenst are
> over.These
> > are internal implenentations transparent from an end user point of view
> and
> > implemented to enhance performnace of the pool-manager.So we could after
> the
> > requirements phase list some critical issues like performance
> > enhancers,bottlenecks,configuration methods ,scalability mechanisms and
> > could have  a detailed discussio on those before proceeding to the design
> > phase.
> >      I need your comments on these, esp Isabelle.
> > - Amit
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Javtools-poolmngr mailing list
> > Jav...@li...
> > https://lists.sourceforge.net/lists/listinfo/javtools-poolmngr
> >
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Javtools-poolmngr mailing list
> Jav...@li...
> https://lists.sourceforge.net/lists/listinfo/javtools-poolmngr


=====
Stefaan Delanghe
ICQ: 110055343

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

[Javtools-poolmngr] standard for threading issues

[Isabelle M. <met...@pa...>]

Hi everyone,

I'd like to suggest Doug Lea's util.concurrent package. It is extremely =
well done and tested, and has all your multithreading hearts could =
desire.
http://gee.cs.oswego.edu/dl/


isabelle

Re: [Javtools-poolmngr] Suggested course of action

[Isabelle M. <met...@pa...>]

Personally, I think that for the first release the requirements should be :

(1) provide pooled connections to users
(2) the connections in one pool can be either all the same type of JDBC
connection (same connection URL, username/password) or they can be different
type. An other alternative would be to have more than one pool, and each
pool is homogeneous.
(3) the user protocol is : borrow, use, return.
(4) we can set some policies as to how long a connection may be in use
(difficult in real life, because a very busy servlet might hold on to the
connection for a long time)
(5) the pool is self-regulating : grows when connection demand is intensive,
shrinks when less demand
(6) configuration thru XML config file

IMO these are sufficient for a first release.

isabelle

----- Original Message -----
From: "Amit Deshpande" <ami...@ra...>
To: "PoolManager (E-mail)" <Jav...@li...>
Sent: Friday, August 02, 2002 8:24 AM
Subject: [Javtools-poolmngr] Suggested course of action


> Hi All,
>          Suddenly there's a lull ...
> anyway how about getting the requirements from a user point of view listed
> first,
> we already have a few requirements listed.
> We could have a look ta some existing pool managers  and jot down some
> features which are missing and are desired.
> We could then freeze the requirements.Lets not mix the technical
discussions
> with these.
>        As far as the technical discussions like server crash,chunking etc
> are concerned lets get to tackle those after the requiremenst are
over.These
> are internal implenentations transparent from an end user point of view
and
> implemented to enhance performnace of the pool-manager.So we could after
the
> requirements phase list some critical issues like performance
> enhancers,bottlenecks,configuration methods ,scalability mechanisms and
> could have  a detailed discussio on those before proceeding to the design
> phase.
>      I need your comments on these, esp Isabelle.
> - Amit
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Javtools-poolmngr mailing list
> Jav...@li...
> https://lists.sourceforge.net/lists/listinfo/javtools-poolmngr
>

[Javtools-poolmngr] Contact Info

[Isabelle M. <met...@pa...>]

Here is my Contact Info:
  =20
  Name               :  Isabelle Muszynski
  Sourceforge Handle :  isabellem
Jabber ID : bo...@ja...
  ICQ ID             :  -
  Yahoo ID           : =20
  Web Email          :  isa...@pr...
  Work Email         : =20
  Country            :  Belgium
  City               :  Antwerp
  Preferred timings  :  (my local time): 14:00-18:00 during weekends
  Languages          :  English,German, french, Dutch

> > > Hi,
> > > Could each of the team members share the
> following information : -
> > > Name
> > > Sourceforge Handle=20
> > > ICQ ID=20
> > > Yahoo ID
> > > Web Email
> > > Work Email
> > > Country
> > > City
> > > Preferred timings for a chat session(your local
> time) We will do the
> > > trnslation into GMT ;o)
> > >=20
> > > This will help us organize a chat session for
> the team via the
> > > internet
> > > whenever necessary.

Re: [Javtools-poolmngr] Craching server

[Isabelle M. <met...@pa...>]

Let's look at 3 scenarios :

(1) no crashes, but user forgets to commit their transaction. I'm saying
that's their problem.
(2) the user returns a connection to the pool and has forgotten to commit.
We should rollback.
(3) the client crashes - we need to find out whether the database will
notice and close the connection.Besides, there's no good way for us to know
that the client is no longer there, aside from implementing a heartbeat.

Isabelle

----- Original Message -----
From: "Stefaan Delanghe" <st...@ya...>
To: "Isabelle Muszynski" <met...@pa...>
Sent: Wednesday, July 31, 2002 9:26 PM
Subject: Re: [Javtools-poolmngr] Craching server


> I don't know what you mean with this. This issue taks about
> the application interupts which have nothing to do with the
> cache manager.
>
> Stefaan
>
>
> --- Isabelle Muszynski <met...@pa...> wrote:
> > I don't think the cache manager should commit or rollback, this is the
> > domain of whomever borrowed the connection from the pool. At most you
should
> > always rollback for in case they forgot to either commit or rollback.
> >
> > Isabelle
> >
> > ----- Original Message -----
> > From: "Stefaan Delanghe" <st...@ya...>
> > To: <jav...@li...>
> > Sent: Wednesday, July 31, 2002 3:54 PM
> > Subject: [Javtools-poolmngr] Craching server
> >
> >
> > >
> > > I though of another issue which may occure during the execution of
> > transactions.
> > >
> > > When a user request a transaction and this is being executed
(connection
> > taken) it
> > > could be that the user interupts the complete application (for example
> > craching pc
> > > or closing a web browser).
> > >
> > > This means that a transaction is executed while this is not neccessary
> > anymore for
> > > the user who requested it.
> > > In light of this matter the transaction MAY NOT be executed since the
> > application
> > > terminated in a abnormal manner.
> > >
> > > This occurence happens the most on a web application.
> > >
> > > For example:
> > >
> > > user request jsp page which executes several statements.
> > > But click on the stop button or closes the window.
> > > Then the transactions on the requested jsp page may not be executed.
> > >
> > > Your comments
> > >
> > > Stefaan
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > =====
> > > Stefaan Delanghe
> > > ICQ: 110055343
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Yahoo! Health - Feel better, live better
> > > http://health.yahoo.com
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by: Dice - The leading online job board
> > > for high-tech professionals. Search and apply for tech jobs today!
> > > http://seeker.dice.com/seeker.epl?rel_code=31
> > > _______________________________________________
> > > Javtools-poolmngr mailing list
> > > Jav...@li...
> > > https://lists.sourceforge.net/lists/listinfo/javtools-poolmngr
> > >
> >
>
>
> =====
> Stefaan Delanghe
> ICQ: 110055343
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>

[Javtools-poolmngr] Suggested course of action

[Amit D. <ami...@ra...>]

Hi All,
         Suddenly there's a lull ... 
anyway how about getting the requirements from a user point of view listed
first,
we already have a few requirements listed.
We could have a look ta some existing pool managers  and jot down some
features which are missing and are desired.
We could then freeze the requirements.Lets not mix the technical discussions
with these.
       As far as the technical discussions like server crash,chunking etc
are concerned lets get to tackle those after the requiremenst are over.These
are internal implenentations transparent from an end user point of view and
implemented to enhance performnace of the pool-manager.So we could after the
requirements phase list some critical issues like performance
enhancers,bottlenecks,configuration methods ,scalability mechanisms and
could have  a detailed discussio on those before proceeding to the design
phase.
     I need your comments on these, esp Isabelle.
- Amit 

Re: [Javtools-poolmngr] Craching server

[Amit D. <ami...@ho...>]

In response to john kellys mail :
I did have this in mind but
this means each jsp spawns 2 threads viz a poller and one which interacts 
with the pool manager to get data.
the pooler (by some http method let that not bother us now) might figure out 
if the client ahs dicsonnected and will stop the other thread.
   The first issue that comes to my mind is ... we should not handle the 
response object.Its bad practice handling the response/request other than 
the scope of the web server (which our PoolMgr wud be)
   Secondly it makes a basic assumption that this poolManager will be used 
by HTTP Clients only.
   Also if we stick to the threads spawned by each JSP , we might end up 
choking the JVM by spawning a large no of threads,this can very much happen 
in large volume sites.
Plz comment
- Amit




>From: John Kelly <joh...@ya...>
>To: jav...@li...
>Subject: Re: [Javtools-poolmngr] Craching server
>Date: Wed, 31 Jul 2002 09:01:52 -0700 (PDT)
>
>A possible solution, even though I might be way off
>the mark here, might be to somehow access the actual
>HTTP Connection (HttpURLConnection) and use this to
>constantly monitor the state of the client. This could
>be done using a light-weight thread with a simple
>polling algorithm. The thread sends a message/event
>the moment the client terminates the connection or
>invalidates the session.
>
>I'm not sure how, but I'm guessing there is some way
>to access the actual HTTP socket and monitor its
>state.
>
>Please Comment.
>
>John.
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Health - Feel better, live better
>http://health.yahoo.com
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: Dice - The leading online job board
>for high-tech professionals. Search and apply for tech jobs today!
>http://seeker.dice.com/seeker.epl?rel_code=31
>_______________________________________________
>Javtools-poolmngr mailing list
>Jav...@li...
>https://lists.sourceforge.net/lists/listinfo/javtools-poolmngr




_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Re: [Javtools-poolmngr] Craching server

[John K. <joh...@ya...>]

A possible solution, even though I might be way off
the mark here, might be to somehow access the actual
HTTP Connection (HttpURLConnection) and use this to
constantly monitor the state of the client. This could
be done using a light-weight thread with a simple
polling algorithm. The thread sends a message/event
the moment the client terminates the connection or
invalidates the session.

I'm not sure how, but I'm guessing there is some way
to access the actual HTTP socket and monitor its
state.

Please Comment.

John.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: [Javtools-poolmngr] Craching server

[Stefaan D. <st...@ya...>]

When a user interupts the program by clicking for example the stop button the jsp
page is still executed. 
Which means that the transactions will be executed while they MUST NOT be executed.

Commenting on your test scenario, the web server only receives a io exception at the
end of the execution of the jsp page.

We should normally capture such execptions and act accordingly.

How to solve this problem??????

Stefaan 



=====
Stefaan Delanghe
ICQ: 110055343

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: [Javtools-poolmngr] Craching server

[Stefaan D. <st...@ya...>]

Hi Amit,

The problem I stated I got from other people who have a simular situation although
it was not in java. These were in fact on a cfm (Coldfusion) and asp.
I did not know how a jsp page would react to it.

In someother situations. I had people discussing in fact that a query was executed
enduassly because of an interuption of some sort in the application.

the problem on web pages would be that a pool manager will be put in a application
scope.

How to you resolve such situations when a session interruption occurs?

Stefaan





=====
Stefaan Delanghe
ICQ: 110055343

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: [Javtools-poolmngr] Craching server

[Amit D. <ami...@ho...>]

Now if we consider that the pool mamager is called from a JSP/Servlet the 
following happens when a jsp/servlet's browser window is closed or the stop 
button is pressed.

The servlet/jsp is a thread which continues to execute in the servlet 
container even if a stop button or browser window is closed only after the 
jsp/serlet thread has finished its task will an IO Exceotion be thrown that 
too to the web server.

Plz comment.
- Amit


>From: Stefaan Delanghe <st...@ya...>
>To: jav...@li...
>Subject: [Javtools-poolmngr] Craching server
>Date: Wed, 31 Jul 2002 06:54:55 -0700 (PDT)
>
>
>I though of another issue which may occure during the execution of 
>transactions.
>
>When a user request a transaction and this is being executed (connection 
>taken) it
>could be that the user interupts the complete application (for example 
>craching pc
>or closing a web browser).
>
>This means that a transaction is executed while this is not neccessary 
>anymore for
>the user who requested it.
>In light of this matter the transaction MAY NOT be executed since the 
>application
>terminated in a abnormal manner.
>
>This occurence happens the most on a web application.
>
>For example:
>
>user request jsp page which executes several statements.
>But click on the stop button or closes the window.
>Then the transactions on the requested jsp page may not be executed.
>
>Your comments
>
>Stefaan
>
>
>
>
>
>
>
>=====
>Stefaan Delanghe
>ICQ: 110055343
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Health - Feel better, live better
>http://health.yahoo.com
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by: Dice - The leading online job board
>for high-tech professionals. Search and apply for tech jobs today!
>http://seeker.dice.com/seeker.epl?rel_code=31
>_______________________________________________
>Javtools-poolmngr mailing list
>Jav...@li...
>https://lists.sourceforge.net/lists/listinfo/javtools-poolmngr




_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

[Javtools-poolmngr] Craching server

[Stefaan D. <st...@ya...>]

I though of another issue which may occure during the execution of transactions.

When a user request a transaction and this is being executed (connection taken) it
could be that the user interupts the complete application (for example craching pc
or closing a web browser).

This means that a transaction is executed while this is not neccessary anymore for
the user who requested it.
In light of this matter the transaction MAY NOT be executed since the application
terminated in a abnormal manner.

This occurence happens the most on a web application.

For example:

user request jsp page which executes several statements.
But click on the stop button or closes the window.
Then the transactions on the requested jsp page may not be executed.

Your comments

Stefaan







=====
Stefaan Delanghe
ICQ: 110055343

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: [Javtools-poolmngr] Contact Info

[Dmitry T. <td...@qu...>]

My contact info:

Name:                       		Dmitry
Sourceforge Handle:			tda
ICQ ID:					42625840	
Yahoo ID:				none
Web Email:				tru...@bi..., tru...@uk...
Work Email:				td...@qu...
Country:				Ukraine
City:					Kiev
Preferred timings for a chat session (your local time): 11:00 - 20:00 (GMT+2).

[Javtools-poolmngr] Contact Info

[Amit D. <ami...@ra...>]

Hi,
Could each of the team members share the following information : -
Name
Sourceforge Handle 
ICQ ID 
Yahoo ID
Web Email
Work Email
Country
City
Preferred timings for a chat session(your local time) We will do the
trnslation into GMT ;o)

This will help us organize a chat session for the team via the internet
whenever necessary.

Well id start with mine
Name :                       	Amit 
Sourceforge Handle    	amythical
ICQ ID 			65682083
Yahoo ID		amythical
Web Email		ami...@ho...	
Work Email		ami...@ra...	
Country			India
City			Bombay
Preferred timings for a chat session (your local time) : 11 pm onwards any
day .

Regards,
Amit

[Javtools-poolmngr] Chunking

[Amit D. <ami...@ra...>]

In response to Isabelle
"I'm also not clear on how you see the technical implementation of chunking.
Let's say the query is "select * from authors where first_name like 'ISA%'.
How are you going to tell the database to return only N rows? I don't think
you can. "
We can do that by limiting the records in the SQL queries.
The reson i though about "chuncking" was (I have discussed thsi with stefaan
but this isnt a part of the mailing list) so id state my reasons for
documentation and for every 1 to comment :
The basic design behind this pool manager is using a limited no of physical
connections to execute transactions(statments) lined up on a  stack and
executed serially.
Now a large query (Query generating a large amount of resultSet) would hold
the physical connection for a long time deprieving execution of otehr
queries on the stack.
Stefaan came up witha  solution as having a pool of physical connection
internally for the pool manager.
So we had other free connections even if there was a large query being
executed .
So do we still need to worry about chunking or we cud stop worying abt it
affecting the performance ?
Plz comment.
There was a dicsussion on the lines of caching query results sets well this
is a no-no i feel.
- Amit

[Javtools-poolmngr] Re: caching

[Stefaan D. <st...@ya...>]

Regarding the cache management in a pool mngr I already added my comment on this.
Disatvange a lot of memory use for caching of those resultsets.

As to comment of Adrian I completely agree. A pool mngr on itself is already a
variant of a caching type. 

Altough regarding his request of a database caching utility I don't agree. 
Currently there is a caching manager available. This utility has the possibility to
cache any types of object including resultsets. So a simple caching tool is already
sufficient enough. Maybe this is a confusion to the naming of Adrian by the database
caching.

Could have some explanation of adrian?

You did not start a flame ware here. :-)
Cause as you I have also my opinion about this caching. 
This is not the best solution regarding to performance in the long run.

Please comment!!

Stefaan

=====
Stefaan Delanghe
ICQ: 110055343

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: [Javtools-poolmngr] Re : Chunking

[Adrian A. <aal...@ca...>]

i think caching is up to the user, it needs to be configurable.
IMHO its better to have 2 separate projects, 1 Database Pool and the =
Other Database Caching.

WHY ? Because if someone  implemented their own JDBC Connection Pool =
Manager, the only thing they want is a software to make some database =
("Resultset, x, y, z") caching and it would be helpful.

How ? We make it receive the resultsets you want to catch and set How =
many time you will have that result in memory, and other options.

This project is about tools not a full "Tool" to use just one feature.

I dont want to start a flame war  ;)

Cheers,

Adrian

Re: [Javtools-poolmngr] Requirements added

[Adrian A. <aal...@ca...>]

 I think LOG4J is the best of the breed for logging.

 Also, i want to point out, We are going to use Jakarta-ant as the main
build
 tool ?

 if your answer is 'YES' we need to start with ant 1.5 and i can make an ant
 task called 'download' so you dont need to download by hand some other jars
 you need for building this project or all the projects in jtools !

 you need only to do:
 ant download
 ant
 and ready, you just only need to set build.properties for your needs.

 Cheers,

 Adrian

[Javtools-poolmngr] Caching resultsets

[Stefaan D. <st...@ya...>]

I have some serious thought about caching resultset. How large a cache of resultset
can be depends on the transactions which must be executed. If for example it is
usefull to cache 50 resultsets for one application and another demands about a 100
caching resultsets. These demands could go up very fast. 
The reason to point this out is that caching resultsets is only usefull in
situations where the retriction clause is not to restrictive (as pointed out by
Isabelle). 
This means that a resultset that could be cached would take alot of memory space on
a application server. 
As in accumulation of the above, there could be litterly put houndreds of resultsets
in the cache which leads to memory overloading of the server.

One possibility to this could be restricting the cache to a certain amount of memory
which seems very far fetched to me.

A pool manager should be capable of turning on any kind of machine powerfull or not.

Your opinion?

Stefaan
 

=====
Stefaan Delanghe
ICQ: 110055343

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

[Javtools-poolmngr] Re : Chunking

[Isabelle M. <met...@pa...>]

Hi everyone,

I don't think chunking is a good idea, it doesn't scale well (as Amit =
pointed out), plus the databases already do it. For example, if you send =
a query for 10000 rows to Oracle, it sends it back in chunks of =
something like 50 rows. The model underlying resultsets is that a cursor =
is opened, and then there are repeated fetches until there is no more =
data.=20

I'm also not clear on how you see the technical implementation of =
chunking. Let's say the query is "select * from authors where first_name =
like 'ISA%'.
How are you going to tell the database to return only N rows? I don't =
think you can. So the only thing you can do is sit there waiting for =
data, collecting it until there are N items, and then pass them on to =
the user. What have you gained in doing that? IMO : nothing.

What might be useful, though, is the possibility to cache a resultset =
(i.e. save it so that the query doesn't have to be executed next time =
around). But :

(1) a piggish user might use up all available memory for one gigantic =
query, so you need to have policies in place for max space per =
connection
(2) you need a policy for invalidating stale data (that has been sitting =
there for a long time without being requested)
(3) you might to collect usage patterns for each cached resultset, and =
adapt the cache to that pattern. For ex. if there are 10000 rows in the =
cache, but in 100 requests nobody ever went beyond row 1000, you might =
as well throw out the last 9000. Think searches on search engines : how =
many times do you look at the 11th page?
(4) you need a notion of "cache-ability". For example, there would be no =
point in saving "select * from authors where first_name =3D 'Ronald" and =
last_name =3D 'Reagan'. (too specific =3D=3D> likelihood of being =
requested again too small)


Isabelle

Re: [Javtools-poolmngr] Requirements added

[Dmitry T. <td...@qu...>]

What software for logging are you planning to use?
And one more questions. What JDK version are planned to use for project?

Amit Deshpande wrote:

>
> Hi,
>   in response to using LOG4J.We would be relying on some other 
> software a.k.a log4J which i am some what I think would be a dependency.
>
>> Amit Deshpande wrote:
>>
>>> 1.Logging - Preliminary in the first version, advanced logging features
>>> could be looked into in a later version.
>>>   User has the option to enable/disable logging.
>>>
>> Propose use for logging LOG4J: 
>> http://jakarta.apache.org/log4j/docs/index.html
>

Re: [Javtools-poolmngr] Requirements

[Dmitry T. <td...@qu...>]

I suppose that debug mode will be invisible for user.
I imagine this mode as following. PM has collection of "free" resources 
and collection of "using" resources. For simplicity I describe life 
cycle for connections. When user get connection then is created object 
with debug info and put this object to "using" resources. When 
connection is returned by user then debug info is removed from "using" 
collection. Thus we will have collection of "using" objects (with debug 
info) at "current" time point. Therefore with help of debug info we can 
decide what resources are not released for long time and can be 
potential "leaks". In debug info object we can store resource object, 
datetime when it has been taken up and stack trace that describe who 
took up resource.

Amit Deshpande wrote:

> Well in that case the user will have to supply us with an identifier 
> for each resource obtaining a connection which we store as apart of 
> the connection object.
> How do we accomodate this resourec identifier for debugging purposes 
> only ?
> - Amit
>
>> Stefaan Delanghe wrote:
>>
>>> 5.A unused connection "sweeper", liken this to a garbase collector , 
>>> unused
>>> connections or timed out connections not returned to the   pool are 
>>> regained.
>>>
>> I think that pool manager (PM) must has debug mode. In this mode PM 
>> have to keep a list of records when and who (this can be stack trace) 
>> get some rsource and didn't release it for some time period. This 
>> future will help to debug "resource leaks".
>