> These are already used for updates/inserts, but I do not think that
> using them for queries will have much impact performance-wise, as you
> need to use teh smae inatance of a statement again to gain performance,
> and statements are immediately discarded after running.
I think prepared statements for select queries can be helpful for two
reasons:
- Performance, you are right about your statement, but application servers
like
WebSphere use prepared statement caches to enhance performance.
I think such a cache can also be implemented in the mmbase connection pool
mechanism. (Maybe something for the performance project).
- Simplicity, A lot of differences in data representation in sql queries
between databases can be solved using prepared statements.
....and why not use them, they are more simple to implement as non prepared
statements.
> > - Concurrency control (If i'm editing the document at the same time as
> > someone else, the first to save hist content wins and the other one
receives
> > a message that the content has been changed since he started editing it)
>
> This should be the task of MMBase, either the TemporaryNodeManager or
> the application that uses it. The database can't handle this as you need
> to maintain a connection to use database locking.
I agree, you don't want to use locking.
> It can be sued when you sue transactions to put a batch of data in, but
> otherwis eit is very hard to do on a multi-user system wiotha limited
> numbe rof connections.
> Not that the Dove, the xml-communication tool used by the editwizards,
> does have a certain 'concurrency' checking, but this is AFTER you are
> done editing (it generates an error if you attempt to commit a node that
> was changed after you retrieved it for editing).
This is what i mean check after you have been editing if the data you have
been editing on is still the same.
I wrote a design pattern for this solution once.
> > - Scrollable resultsets in case of large query results
>
> Also a bit hard to create due to the limited number of connections.
I think in a web application you don't want to have connections open for
more than one request.
This can be killing for your performance. The huge cost for queries with
large result sets, is loading
the database data a objects in java. In general when a large result set is
asked by a user, he only uses
the first 50 resulting objects. I once calculated for an application, that
it was better to do the query,
get the first 50 results, close the connection (return it to the pool), and
when the second window (page) was asked,
do the query again, ignore the first 50 results, get the next 50 results and
close the connection. The big advantage of
this solution is also that the memory footprint of your application stays
controllable.
(This mail is also an answer to the reaction of Eduard Witteveen)
Gerard van de Looi
E-id! Internet Strategies
<design-pattern>
<name>concurrency ticket pattern</name>
<author>Gerard van de Looi</author>
<date>21-03-2002</date>
<keywords>
<keyword>concurrency control</keyword>
<keyword>data access</keyword>
<keyword>web application</keyword>
<keyword>jdbc</keyword>
</keywords>
<introduction>
Data access objects is a popular alternative for entity beans with
container
managed persistency. One of the major disadvantages of the use of data
access
objects is that most implementations do not have a concurrency control
mechanism
or that a custom concurrency control mechanism has to be written.
This design pattern provides a generic concurrency control mechanism
with pluggable
concurrency control algorithms.
</introduction>
<problem>
Web applications using J2EE technology are currently widely used. Most
implementations
have a custom build implementation for data storage, because of some
drawbacks in the
use of entity beans. But most implementations lack a concurrency
control mechanism.
The concurrency control mechanism for web applications has some
specific requirements.
Objects may not be locked for too long and certainly not when user
interaction is still
needed. The memory foorprint to solve the locking problem has to be as
small as possible.
</problem>
<solution>
<p>
We want concurrency control to be configurable per class, since not
all classes have
concurrent updates (readonly objects, objects that are only accessible
for one user).
To solve this we introduce the ConcurrencyControlledObject interface.
Each object that implements this interface will have concurrency
control while updating
or deleting the object.
</p>
<p>
The main issue of concurrency control using optimistic locking is to
match the data before
the changes where made with the data retrieved from the database when
the lock is retrieved.
In this pattern the identification of this data is called the ticket.
The ticket can be of
any class, which gives us maximum flexibility.
The concerrency controlled object has to implement two methods, one to
set the ticket and
one to get the ticket. The getter method has to return the exact
ticket that was earlier
set with the setter method.
</p>
<p>
There are various ways to retrieve a ticket from a set of data. This
pattern accepts any
object array as the raw data that needs a ticket to be calculated.
Since there are multiple ways
to calculate a ticket from the raw data, the real ticket calculation
algorithm is implemented
using an interface and an implementation class that can be changed on
initialization.
This allows us to use for instance an update counter algorithm or a
timestamp algorithm.
</p>
<p>
The concurrency control algorithm (ConcurrencyControlAlgorithm)
implements two methods. The first
one is to calculate a ticket from the raw data. The second one is to
compare the equality of two
tickets.
</p>
<p>
To connect the concurrency controlled objects with the concurrency
control algorithm, we use a
concurrency controller (ConcurrencyController). Using the singleton
design pattern, a single
instance of this class is forced. The single instance has a reference
to the concurrency control
algorithm.
The concurrency controller has three public methods. One to indicate
if an object needs concurrency
control. One to set the ticket with a concurrency controlled object,
based on the given raw data and
one to see if the ticket of a concurrency controlled object is still
valid.
</p>
<p>
The concurrency ticket pattern is independent of the kind of datastore
that is used. The locking and
use of the concurrency controller has to be implemented with the
database access classes, for instance
as described in the advanced data access object pattern.
</p>
</solution>
<advantages>
<advantage>Concurrency control is provided for web
applications</advantage>
<advantage>Custom concurrency control algorithms can be
implemented</advantage>
</advantages>
<related-patterns>
<pattern>singleton_pattern.xml</pattern>
<pattern>advanced_data_access_object_pattern.xml</pattern>
</related-patterns>
</design-pattern>
