InterClient und Apache

[Andreas Tengicki]

Hi,

ich setzte InterBase 6, mit InterClient 1.6 unter FreeBSD mit Apache und JServ ein. Dabei stellt sich die Frage wie man am besten die Datenbank Connection handhabt. Bei parallelen Zugriffen auf den Webserver, was ja vorkommen soll, legt der Apache automatisch soviele parallele Servlets an, wie er braucht und benutzt diese später auch wieder.

Sollen nun alle Servlets über eine DB Connection laufen?

Oder jedes Servlet eine eigene IB Connection bekommen?

Habe beide Versionen versucht und es ist einfach instabil. Es gibt Fehlermeldungen vom InterClient, meistens irgendwelche Bug Nummern.

Gibt es Tipps ob der Einsatz vom InterClient 2.0 lohnt, nach unseren Versuchen eher nicht.

Freue mich über jeden Tipp, Quelle, Lösung ..

p.s. Am Servlet sollte es nicht liegen, denn gegen Oracle ist es wundersam stabil.

[tp]

Hi Andreas,

zur Architekturfrage: hier ist die Nutzung einer JDBC DataSource angebracht. Diese liefert Connections, welche beim close() nicht wirklich die DB-Con schließen, sondern die Verbindung zurück in einen Pool legen. Solltest Du keinen J2EE AppServer haben (wollen), kann man sich dieses Verhalten auch leicht selbst implementieren:

<CODE>
public MyDataSource implements DataSource<BR>
{<BR>
<BR>
public Connection getConnection()<BR>
{<BR>
Connection result = getUnusedConnection();<BR>
markAsUsed(result);<BR>
return result;<BR>
}<BR>
<BR>
public MyDBConnection extends/wraps IBConnection<BR>
{<BR>
<BR>
public void close()<BR>
{<BR>
markAsUnused(this);<BR>
} <BR>
<BR>
}<BR>
<BR>
}<BR>
</CODE&gt

[Andreas Tengicki]

Hallo Thomas,

das tue ich doch schon, insbesondere um auch die Garbarge Collcetion nicht bemühen zu müssen. Sprich einiges an häufig genutzen Objekten ist in einem MemoryPool gespeichert.

Aber Du würdest empfehlen je Servlet-Instanz eine eigene DB Connection zu verwenden

[tp]

???

Wieso, die Servlets verwenden den Pool - eine DB-Verbindung pro Servlet ist etwa so wie mit 20 Leuten auf Urlaubsreise zu gehen, wobei jeder sein eigenes Kreuzfahrtschiff hat. Ziemlicher Luxus, halt. Außerdem hast Du ein Problem, wenn Du die DB Conn als Attribut eines Servlet anlegst - viel Spaß beim synchronize ieren, wenn es mal nicht Apache sein soll. Öffnest Du dagegen in der kritischen Methode die Verbindung über den Pool, bist Du aus dem Schneider, und es wird portabel. Es gibt Leute, die schwören z.B. auf Resin und wollen nix von Apache hören.<br>
Klar, Oracle und Apache im Team sind ein gutest Team: MTS auf der DB und Servlet-Pools in der Servlet-Engine. Soll die App nur dort laufen, gib jedem der 20 Leute sein eigenes Schiff

c

[Andreas Tengicki]

Hallo Thomas,

Große Verwirrung . So habe ich es zuvor getan. Eine einizige statische Connection, die wurde den Servlet-Instanzen zur Verfügung gestellt und die konnten ihre PreparedStatements holen. Doch leider knallt das wenn ein Zugriff von zwei Instanzen des gleichen Servlets stattfindet, und zwar mit InterClient Fehlern, sonst würde ich ja woanders suchen und nicht in der Datenbank.

Was kann man denn da (typischerweise) falsch machen

[tp]

Andreas,

ich glaub, wir reden aneinander vorbei. Eine DataSource besagt, daß mehrere Verbindungen offen sind. Mit Hilfe von getConnection() holt man sich eine ab, welche dann nur dem Aufrufer selbst zur Verfügung steht. In Wirklichkeit allerdings bekommt man einen Wrapper um die tatsächliche Connection (sollte der JDBC-Treiber die DataSources nicht unterstützen), ein close() Aufruf an der Verbindung bringt diese zurück in den Pool.<br>
An der DataSource kann die Größe des Pool sowie seine increment- und shrink-Size eingestellt werden.<br>
Wenn Du immer noch nicht weißt, was ich meine, schau mal in den JDBC Extensions (JDBC2) oder in der JDBC3 Spec nach. Beispiele (zur Nutzung etwa innerhalb, aber nicht ausschließlich, eines AppServer) findest Du bei der J2EE RefImpl. von Sun (BMP-Beispiele) oder bei WebLogic (Stichwort bei 5.1: weblogic.properties, database pools).

Du schreibst:<br>
&gt; Eine einizige statische Connection, die wurde den <br>
&gt; Servlet- Instanzen zur Verfügung gestellt und die <br>
&gt; konnten ihre PreparedStatements holen.
In dem Falle wäre nur die DataSource statisch, während die Connections von jedem Servlet "aus-" und "eingecheckt" werden können.

Puh... ;

[Andreas Tengicki]

Thomas,

erst mal danke für die Hilfe, ich muß also etwas tiefer in die Innereien des JDBC, habe ich es mir zu leicht gemacht. Nun denn.

Ich melde mich in einem neuen Thread wenn ich nicht weiterkomme

[tp]

Klar Wenn in diesem Thread keiner mehr reinschaut, schick ne Mail

[Andreas Tengicki]

@Thomas

So soll das also gehen, mit der DataSource. Klingt ja gut, aber

In der InterClient 1.6 Dokumentation, den wir derzeit noch einsetzen steht, das DataSource voraussichtlich ab InterClient 2.0 realisiert wird. Ist dem so? Ist InterClient 2.0 (unter FreeBsd JSDK 1.2) stabil? Wir hatten schon unter Windows mit dem Teil so unsere Probleme

[tp]

Hi Andreas,

sorry, aber habe irgendwie den Faden mit den IB-Versionen verloren, weil ich schon lang nicht mehr mit IB gearbeitet habe
<P>
Generell gibt es eine DataSource-Implementierung seit IB 5.5 und dem dazugehörigen InterClient, aber Du kannst Dir ja selber eine bauen. Siehe Quelltext oben
<p>
c

[tp]

Beim surfen bin ich grad auf http://www.codestudio.com gestoßen - nennt sich PoolMan und ist Open Source. Kennt das jemand