You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Jørgen Løland <Jo...@Sun.COM> on 2007/11/13 14:35:27 UTC
Restricting number of connections from a single user
A client/server Derby will soon be used in a university course to teach
students SQL etc.
Previous experience has revealed that students who are not familiar with
Java programming and JDBC/DBs tend to open a new connection for every
Statement. There will be peaks with a few hundred concurrent users. Is
there any way of restricting the number of connections a user can open
in Derby? I want the faulty student applications to get exceptions
rather than ruining the user experience for the "nice" users.
--
Jørgen Løland
Re: Restricting number of connections from a single user
Posted by Jørgen Løland <Jo...@Sun.COM>.
That's spot on, Thomas. The students should understand that they are
doing something stupid.
A workaround (to force bad apps to fail) could be to start out with an
embedded Derby that only accepts a connection or two before failing.
That is, unless the maxthread option only works for client/server.
Thomas Nielsen wrote:
> I believe Jørgens angle of attack here is that a badly programmed app
> would still thrive in embedded mode, and the student would never get
> that he is misbehaving?
>
> Limitations on server access would quickly foster nice, pure code in
> this area - at least if there were some helpful exceptions thrown.
>
> But, yes, going embedded would certainly help in a lot of other areas!
>
> I guess the possibility of going embedded was never really on their
> mind. Enlightenment is one of the challenges of [pre|te]aching derby to
> those in a Oracle/Mysql mindset... :)
>
> Thomas
>
> Rick Hillegas wrote:
>> Why do they need a client-server setup, at least to start out with? I
>> would think that the course could start out with every student running
>> embedded against their own Derby database on their own laptop.
>> Embedded usage seems to me to be one of the great appeals of using
>> Derby in the classroom: it insulates students from all sorts of other
>> mistakes that other beginners may be making and it lets the students
>> take their homework off-campus and off-network. I would be tempted to
>> introduce client/server later on in the course after the students have
>> learned enough to be cautious about mistakes like opening too many
>> connections
>
--
Jørgen Løland
Re: Restricting number of connections from a single user
Posted by Thomas Nielsen <Th...@Sun.COM>.
I believe Jørgens angle of attack here is that a badly programmed app
would still thrive in embedded mode, and the student would never get
that he is misbehaving?
Limitations on server access would quickly foster nice, pure code in
this area - at least if there were some helpful exceptions thrown.
But, yes, going embedded would certainly help in a lot of other areas!
I guess the possibility of going embedded was never really on their
mind. Enlightenment is one of the challenges of [pre|te]aching derby to
those in a Oracle/Mysql mindset... :)
Thomas
Rick Hillegas wrote:
> Why do they need a client-server setup, at least to start out with? I
> would think that the course could start out with every student running
> embedded against their own Derby database on their own laptop. Embedded
> usage seems to me to be one of the great appeals of using Derby in the
> classroom: it insulates students from all sorts of other mistakes that
> other beginners may be making and it lets the students take their
> homework off-campus and off-network. I would be tempted to introduce
> client/server later on in the course after the students have learned
> enough to be cautious about mistakes like opening too many connections
--
Thomas Nielsen
Re: Restricting number of connections from a single user
Posted by Rick Hillegas <Ri...@Sun.COM>.
Jørgen Løland wrote:
> A client/server Derby will soon be used in a university course to
> teach students SQL etc.
>
> Previous experience has revealed that students who are not familiar
> with Java programming and JDBC/DBs tend to open a new connection for
> every Statement. There will be peaks with a few hundred concurrent
> users. Is there any way of restricting the number of connections a
> user can open in Derby? I want the faulty student applications to get
> exceptions rather than ruining the user experience for the "nice" users.
>
Why do they need a client-server setup, at least to start out with? I
would think that the course could start out with every student running
embedded against their own Derby database on their own laptop. Embedded
usage seems to me to be one of the great appeals of using Derby in the
classroom: it insulates students from all sorts of other mistakes that
other beginners may be making and it lets the students take their
homework off-campus and off-network. I would be tempted to introduce
client/server later on in the course after the students have learned
enough to be cautious about mistakes like opening too many connections
Just my $0.02.
-Rick
Re: Restricting number of connections from a single user
Posted by Jørgen Løland <Jo...@Sun.COM>.
Bernt M. Johnsen wrote:
> Hi,
>
>>>>>>>>>>>>> Jørgen Løland wrote (2007-11-13 14:35:27):
>> A client/server Derby will soon be used in a university course to teach
>> students SQL etc.
>>
>> Previous experience has revealed that students who are not familiar with
>> Java programming and JDBC/DBs tend to open a new connection for every
>> Statement. There will be peaks with a few hundred concurrent users. Is
>> there any way of restricting the number of connections a user can open
>> in Derby? I want the faulty student applications to get exceptions
>> rather than ruining the user experience for the "nice" users.
>
> You may set tha maximum numbers of threads. This will restrict the
> number of *running* connections. When you exceed this number,
> subsequent connections will wait in a queue until a thread is
> available.
>
>
>> --
>> Jørgen Løland
Right, but that means that a faulty application may get all the
connections, effectively denying others from connecting?
--
Jørgen Løland
Re: Restricting number of connections from a single user
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
Well, not quite what you asked for, since this is for the server as a
whole, not per "user".
>>>>>>>>>>>> Bernt M. Johnsen wrote (2007-11-13 14:58:41):
> Hi,
>
> >>>>>>>>>>>> Jørgen Løland wrote (2007-11-13 14:35:27):
> > A client/server Derby will soon be used in a university course to teach
> > students SQL etc.
> >
> > Previous experience has revealed that students who are not familiar with
> > Java programming and JDBC/DBs tend to open a new connection for every
> > Statement. There will be peaks with a few hundred concurrent users. Is
> > there any way of restricting the number of connections a user can open
> > in Derby? I want the faulty student applications to get exceptions
> > rather than ruining the user experience for the "nice" users.
>
> You may set tha maximum numbers of threads. This will restrict the
> number of *running* connections. When you exceed this number,
> subsequent connections will wait in a queue until a thread is
> available.
>
>
> >
> > --
> > Jørgen Løland
Re: Restricting number of connections from a single user
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
Hi,
>>>>>>>>>>>> Jørgen Løland wrote (2007-11-13 14:35:27):
> A client/server Derby will soon be used in a university course to teach
> students SQL etc.
>
> Previous experience has revealed that students who are not familiar with
> Java programming and JDBC/DBs tend to open a new connection for every
> Statement. There will be peaks with a few hundred concurrent users. Is
> there any way of restricting the number of connections a user can open
> in Derby? I want the faulty student applications to get exceptions
> rather than ruining the user experience for the "nice" users.
You may set tha maximum numbers of threads. This will restrict the
number of *running* connections. When you exceed this number,
subsequent connections will wait in a queue until a thread is
available.
>
> --
> Jørgen Løland