Vor- und Nachteile aktueller Programmiersprachen

Computer: Software & Programmierung Programmierung allgemein
#1

Hallo!

Es ist schon eine Weile her, als ich hier das letzte Mal eine Frage gestellt hatte. Aber ich hoffe, ihr könnt mir dennoch Helfen, wie ihr es bisher immer konntet.

Es geht um das beliebte Thema der Programmiersprache. Ich hab auch die Suchfunktion des Forums benutzt (und google), bin aber leider nicht fündig geworden.

Ersteinmal als „Vorwort“. Ich arbeite in einer Softwareforma, die bisher ihre Software vornehmlich in Cobol programmierte. Zwar funktioniert das System im Ganzen, doch in meinen Augen ist diese Sprache ein Relikt aus alten Zeiten und hat ihre Nachteile in der grafischen Darstellung sowie Handhabung von Threads und Internetanbindung. Daher ist die Überlegung am Reifen, langfristig auf ein neues Pferd zu setzen. Was wir dafür benötigen:

  • Threads
  • gute grafische Darstellungsmöglichkeiten (GUI)
  • Kommunikation mit dem Internet (SOAP, Sockets, usw)
  • leichte Handhabung von XML-Daten
  • schöne durchdachte API

Nun komme ich gerade frisch aus dem Studium und habe daher sehr gute Kentnisse mit Java gesammelt. Java vereint eigentlich alle genannten Eigenschaften und wäre von meiner Seite her auch die bevorzugte Sprache. Die API dieser Sprache lässt eigentlich keine Wünsche mehr offen. Dennoch sehe ich leider Probleme mit Java in Bezug auf große Applikationen. In meiner Abschlussarbeit habe ich ein pluginfähiges System zur Meldung von Tickets (Kundenwünsche, -probleme, etc…) entwickelt und dabei festgestellt, dass grafische Komponenten von Java dazu neigen, träge zu sein. Während Windowsprogramme sehr schnell auf Benutzereingaben ragieren, bemerkt man die Trägheit von Java leider deutlich. Nun mache ich mir also Sorgen, wie sich dieses Mängel bei einem noch viel komplexeren System auswirken würden. Hat da schon jemand Erfahrungen gesammelt und Java vielleicht für größere kaufmännische Applikationen eingesetzt?

Meine Überlegungen sind gerade:

  • java wirklich gut für komplexe Anwendungen?
  • c++ besser?
  • oder gleich c#?
  • andere Sprachen?

Punkt zwei und drei ließen sich mit dem .NET-Framework sogar zusammen nutzen. Nur bin ich mir dessen halt noch nicht so sicher. Hoffentlich bekomme ich durch euch irgendwie weitere Infos zu diesem Thema. Oder kennt gar jemand eine Website, auf der mal grobe Vor- und Nachteile der aktuellen Sprachen aufgeliestet sieht?

MfG,
Martin

#2

Hallo Martin

… bisher ihre Software vornehmlich in Cobol programmierte
…

  • Threads
  • gute grafische Darstellungsmöglichkeiten (GUI)
  • Kommunikation mit dem Internet (SOAP, Sockets, usw)
  • leichte Handhabung von XML-Daten
  • schöne durchdachte API

[Java träge]
…
[.NET-Framework]
…

Erstmal ein paar Fragen vorweg.

  • Wozu konkret braucht ihr Threads?
  • Was hat Priorität
    • grafische Darstellung im WWW-Frontend (Browser)
    • grafische Darstellung als Desktop-Applikation
  • Wie ist das Team aufgebaut? Wird es Widerstand leisten :wink: ?

Die kurze Antwort aus der Glaskugel: .NET

vgl. http://weblogs.java.net/blog/johnreynolds/archive/20…

Grüße

CMБ

#3

Hallo an dieser Stelle.

Die kurze Antwort aus der Glaskugel: .NET

Dann wollen wir diese Glaskugel mal ein wenig polieren: http://www.dotnet-magazin.de/itr/ausgaben/psecom,id,… -> „Decompiler und Obfuscator“ sowie den aktuellen Basisthread unter http://www.wer-weiss-was.de/cgi-bin/forum/showarticl…

vgl.
http://weblogs.java.net/blog/johnreynolds/archive/20…

Es kommt auch auf das Design des Datenmodells an.
Und wie stark die Featuritis mit der verwendeten Programmiersprache fortgeschritten ist :wink:

mfg M.L.

#4

Hallo!

Ersteinmal als „Vorwort“. Ich arbeite in einer Softwareforma,
die bisher ihre Software vornehmlich in Cobol programmierte.
Zwar funktioniert das System im Ganzen, doch in meinen Augen
ist diese Sprache ein Relikt aus alten Zeiten und hat ihre
Nachteile in der grafischen Darstellung sowie Handhabung von
Threads und Internetanbindung. Daher ist die Überlegung am
Reifen, langfristig auf ein neues Pferd zu setzen. Was wir
dafür benötigen:

  • Threads
  • gute grafische Darstellungsmöglichkeiten (GUI)
  • Kommunikation mit dem Internet (SOAP, Sockets, usw)
  • leichte Handhabung von XML-Daten
  • schöne durchdachte API

… und dabei festgestellt, dass grafische Komponenten
von Java dazu neigen, träge zu sein. Während Windowsprogramme
sehr schnell auf Benutzereingaben ragieren, bemerkt man die
Trägheit von Java leider deutlich. Nun mache ich mir also
Sorgen, wie sich dieses Mängel bei einem noch viel komplexeren
System auswirken würden. Hat da schon jemand Erfahrungen
gesammelt und Java vielleicht für größere kaufmännische
Applikationen eingesetzt?

Meine Überlegungen sind gerade:

  • java wirklich gut für komplexe Anwendungen?
  • c++ besser?
  • oder gleich c#?
  • andere Sprachen?

Punkt zwei und drei ließen sich mit dem .NET-Framework sogar
zusammen nutzen. Nur bin ich mir dessen halt noch nicht so
sicher. Hoffentlich bekomme ich durch euch irgendwie weitere
Infos zu diesem Thema. Oder kennt gar jemand eine Website, auf
der mal grobe Vor- und Nachteile der aktuellen Sprachen
aufgeliestet sieht?

MfG,
Martin

eigentlich ist der vergleich zu früher eher hinkend

„alte“ programmiersprachen wie zB auch Fortran wurden nie dafür entwickelt, GUIs darzustellen, sondern schnellstmöglichst aus einem gewissen Input ein richtigen Output zu erzeugen

die „neuen“ Programmiersprachen besitzen eine schier unendlich erscheinende Vielfalt an vorgegebenen Funktionen, Klassen und Möglichkeiten, das einige Funktionen der Klassen so gut wie nie gebraucht werden ist egal, weil die funktion dafür wäre ja da, dass man also diesen „funktionsüberschuss“ mitschleppt macht diese Sprachen
dann träger

Java hat zusätzlich den Vor & Nachteil mit dem JRE, es ist zwar überall lauffähig, jedoch kann man nicht auf betriebssystem-abhängige funktionen zugreifen

wenn es weiter Windows sein soll, empfehle ich J#, das standart-windows GUIs benutzt, diese ist schneller, weil die ganzen Kompatibiläts-funktionen wegfallen

mfg
mathias

#5

Hallo Semjon!

Erstmal ein paar Fragen vorweg.

  • Wozu konkret braucht ihr Threads?

In unserem Fall ist es so, dass länger andauernde Prozesse (suchen, kopieren,
konvertieren …) in solche Threads ausgelagert werden sollen, damit die
grafische Oberfläche nicht ‚einfriert‘. Ebenso gibt es asynchrone Ereignisse
wie Nachrichten (unsere Software ist mehrbenutzerfähig) oder
Terminerinnerungen, die per Threads abgerufen werden könnten. Cobol bietet
(laut aussagen unseres Programmierers - ich kenne mich da überhaupt nicht aus)
wohl so ohne Weiteres keine Unterstützung.

  • Was hat Priorität
    • grafische Darstellung im WWW-Frontend (Browser)
    • grafische Darstellung als Desktop-Applikation

Ich meinte die grafische Darstellung auf dem Desktop (Frames, Dialoge, etc)

  • Wie ist das Team aufgebaut? Wird es Widerstand leisten :wink: ?

Nun ja… Wenn man bedenkt, dass hier noch prozedural programmiert wird, ist
die Umstellung definitiv nicht Ohne :smile: Aber in meinen Augen muss eine
Umstellung erfolgen!

Die kurze Antwort aus der Glaskugel: .NET

Zumindest hätte man mit .NET den Vorteil, nicht ganz von der gewählten
Programmiersprache abhängig zu sein. Es gibt auch ein .NET-Cobol. Allerdings
wäre die Kehrseite, dass man so schnell wieder in die alte Gewohnheit
zurückfällt und beispielsweise nicht objektorientiert programmieren würde.
Dennoch bin ich gerade dabei, mich ein wenig mit .NET auseinanderzusetzen.
Glücklicherweise gab es in den letzten IX-Ausgaben einige Artikel über C#
und .NET. Recht interessant!

vgl.
http://weblogs.java.net/blog/johnreynolds/archive/20…

Hab ich mir durchgelesen. Danke für den Link!

Gruß,
Martin

#6

Hallo!

Dann wollen wir diese Glaskugel mal ein wenig polieren:
http://www.dotnet-magazin.de/itr/ausgaben/psecom,id,…
-> „Decompiler und Obfuscator“ sowie den aktuellen
Basisthread unter
http://www.wer-weiss-was.de/cgi-bin/forum/showarticl…

Mit demselben Problem hat man ja auch unter Java zu kämpfen. Sogesehen bliebe
nur der „Ausweg“ über andere (z.b. c++) Anbieter von Entwicklungsumgebungen wie
Borland

Gruß,
Martin

#7

Hallo Mathias!

[…] dass man also diesen „funktionsüberschuss“ mitschleppt
macht diese Sprachen dann träger

Hm, ich bin mir da gar nicht so sicher, ob gerade diese Funktionsvielfalt die
Sprachen träger macht. In dem Sinne wird ja auch nichts ‚mitgeschleppt‘. Die
Methoden sind ja klassengebunden und werden nicht in den Speicher geladen. Der
Aufruf einer von viele Funktionen sollte eigentlich ebenso schnell gehen
können, wie ein Aufruf einer sehr begrenzten Anzahl von Funktionen. Lasse mich
aber gern eines besseren belehren.

Java hat zusätzlich den Vor & Nachteil mit dem JRE, es ist
zwar überall lauffähig, jedoch kann man nicht auf
betriebssystem-abhängige funktionen zugreifen

Genau. Das ist leider das Problem. So schön diese Sprache auch ist, dies ist
ihr größter Nachteil…

wenn es weiter Windows sein soll, empfehle ich J#, das
standart-windows GUIs benutzt, diese ist schneller, weil die
ganzen Kompatibiläts-funktionen wegfallen

Und warum kein c#? Oder kennst Du das nur gerade nicht? Mich würde ja auch
interessieren, was mir die unterschiedlichen Sprachen an Vor- bzw Nachteilen
bieten. Laut meiner Info ist c# ja schon sehr Java-Ähnlich, wobei dann genau an
dieser Stelle die Frage gestattet sein muss, was nun J# von C# unterscheidet…

Gruß,
Martin

#8

Hallo Martin,

Glücklicherweise gab es in den letzten IX-Ausgaben einige
Artikel über C# und .NET. Recht interessant!

Vielleicht wäre das noch zu verwenden …

[C# From a Java Developer’s Perspective]
http://www.25hoursaday.com/CsharpVsJava.html

[Java developer’s view of C#]
http://www.dataart.com/company/knowledge-base/java-d…

Letztlich denke ich, dass für Eure
Situation alles für ein .NET-Umfeld
spricht. Auch deshalb, weil es

  • (a) sanfte Migration ermöglicht (Cobol),
  • (b) Vielfalt erlaubt (J#,C#,VB.NET), falls erforderlich,
  • © Marktmacht dahintersteht, die die Militärmacht des Iran
    in den Schatten stellt, (:-o

Zu © - da gibts den alten wahren Spruch:
„nobody got ever“ http://www.google.de/search?hl=de&q=%22nobody+got+ev…&

Grüße

CMБ

PS.: gute Quelle für Vergleiche:
http://dmoz.org/Computers/Programming/Languages/Comp…

#9

Ich sehe das Problem mit Java noch nicht so recht.

[…] dass man also diesen „funktionsüberschuss“ mitschleppt
macht diese Sprachen dann träger

Hm, ich bin mir da gar nicht so sicher, ob gerade diese
Funktionsvielfalt die
Sprachen träger macht. In dem Sinne wird ja auch nichts
‚mitgeschleppt‘. Die
Methoden sind ja klassengebunden und werden nicht in den
Speicher geladen. Der
Aufruf einer von viele Funktionen sollte eigentlich ebenso
schnell gehen
können, wie ein Aufruf einer sehr begrenzten Anzahl von
Funktionen. Lasse mich
aber gern eines besseren belehren.

In der Tat macht die Fuelle an Funktionen nur sehr kurzfristig etwas aus, wenn die Server-VM erstmal 5 minuten laeuft hat sie sich soweit auf das laufende Programm optimiert, dass sie einem nativen C++ in so gut wie nichts nachsteht, das haben zahlreiche Benchmarks bewiesen. Das optimieren zur Laufzeit ist ein immenser Vorteil, der oft vernachlaessigt wird.

Geht es in diesem Fall nun konkret um eine Server-Applikation, oder eine Anwendung, oder beides?

Java hat zusätzlich den Vor & Nachteil mit dem JRE, es ist
zwar überall lauffähig, jedoch kann man nicht auf
betriebssystem-abhängige funktionen zugreifen

Genau. Das ist leider das Problem. So schön diese Sprache auch
ist, dies ist
ihr größter Nachteil…

…und vollkommen falsch. Man hat uneingeschraenkt Zugriff auf native Funktionen jedes Betriebssystems ohne jegliche Geschwindigkeitseinbuszen, beispielsweise unter Windows kann man einfach in C++, oder was auch immer man bevorzugt, eine dll schreiben welche die gewuenschten Routinen implementiert, und diese dann per JNI (-> http://java.sun.com/j2se/1.5.0/docs/guide/jni/ ) im Java-Programm aufrufen. Hat eben den Nachteil, dass man diese Bibliotheken fuer jedes Betriebssystem schreiben muss, aber das muss man ja so oder so wenn man native Funktionen nutzen moechte.

#10

In der Tat macht die Fuelle an Funktionen nur sehr kurzfristig
etwas aus, wenn die Server-VM erstmal 5 minuten laeuft hat sie
sich soweit auf das laufende Programm optimiert, dass sie
einem nativen C++ in so gut wie nichts nachsteht, das haben
zahlreiche Benchmarks bewiesen. Das optimieren zur Laufzeit
ist ein immenser Vorteil, der oft vernachlaessigt wird.

oder wie mein Prof immer sagte
„Einen schlechten Algorythmus bekommt man durch die beste Sprache nicht schnell“

Java hat zusätzlich den Vor & Nachteil mit dem JRE, es ist
zwar überall lauffähig, jedoch kann man nicht auf
betriebssystem-abhängige funktionen zugreifen

Genau. Das ist leider das Problem. So schön diese Sprache auch
ist, dies ist
ihr größter Nachteil…

…und vollkommen falsch. Man hat uneingeschraenkt Zugriff auf
native Funktionen jedes Betriebssystems ohne jegliche
Geschwindigkeitseinbuszen, beispielsweise unter Windows kann
man einfach in C++, oder was auch immer man bevorzugt, eine
dll schreiben welche die gewuenschten Routinen implementiert,
und diese dann per JNI (->
http://java.sun.com/j2se/1.5.0/docs/guide/jni/ ) im
Java-Programm aufrufen. Hat eben den Nachteil, dass man diese
Bibliotheken fuer jedes Betriebssystem schreiben muss, aber
das muss man ja so oder so wenn man native Funktionen nutzen
moechte.

hier hab ich applets mit applikationen verwechselt, mein Fehler :wink:

mfg
Mathias

#11

Moin Martin

wenn es weiter Windows sein soll, empfehle ich J#, das
standart-windows GUIs benutzt, diese ist schneller, weil die
ganzen Kompatibiläts-funktionen wegfallen

Und warum kein c#? Oder kennst Du das nur gerade nicht? Mich
würde ja auch
interessieren, was mir die unterschiedlichen Sprachen an Vor-
bzw Nachteilen
bieten. Laut meiner Info ist c# ja schon sehr Java-Ähnlich,
wobei dann genau an
dieser Stelle die Frage gestattet sein muss, was nun J# von C#
unterscheidet…

der Umstieg von Java auf J# ist einfacher,
weil J# die (M$-)weiterentwicklung von Java ist

C# ist der Versuch, Vorteile aus C++ und Java zu kombinieren,
sie einfach zu halten(ohne zeiger und referenzen)

C# wird mehr unterstütz, zu J# findet man kaum gute Weblinks
ein Umstieg auf C# wäre also etwas für die Zukunft, für J# dann die kurzfristige Lösung, wegen der kurzen umgewöhnungszeit

mfg
Mathias

#12

Geht es in diesem Fall nun konkret um eine Server-Applikation,
oder eine Anwendung, oder beides?

Z.Zt. eigentlich hauptsächlich um Client-Applikationen. Allerdings stünde einer
späteren Migration in eine Client-Server-Anwendung (wo es dann also ebenfalls
um Serveranwendungen ginge) nichts im Wege. Ich sage also mal: beides

[…] Man hat uneingeschraenkt Zugriff auf
native Funktionen jedes Betriebssystems ohne jegliche
Geschwindigkeitseinbuszen, beispielsweise unter Windows kann
man einfach in C++, oder was auch immer man bevorzugt, eine
dll schreiben welche die gewuenschten Routinen implementiert,
und diese dann per JNI (->
http://java.sun.com/j2se/1.5.0/docs/guide/jni/ ) im
Java-Programm aufrufen. Hat eben den Nachteil, dass man diese
Bibliotheken fuer jedes Betriebssystem schreiben muss, aber
das muss man ja so oder so wenn man native Funktionen nutzen
moechte.

Da hast Du recht! Das habe ich in diesem Fall gar nicht bedacht.
Doch ging es bei mir ja nicht um die native Unterstützung von
Betriebssystem-Calls sondern eher um das Bedenken der flüssigen Reaktion der
Grafischen Elemente von Java. Eigentlich ist das alles, was mir Sorgen
bereitet. Ich merke in kleineren Applikationen die Trägheit der UI von Java im
Vergleich zu anderen Sprachen (die WindowsForms nutzen, oder aber auch QT o.ä.)
schon recht deutlich, und befürchte eben nur, dass sie in größeren Anwendungen
noch zunehmen könnte. Wenn Dich ein Kunde fragt, warum das Programm auf einmal
träger als vorher ist, musst Du erstmal argumentieren können, warum das nun
besser ist als vorher.
Das ist eigentlich meine ganze Sorge…

Gruß

#13

Allerdings stünde einer
späteren Migration in eine Client-Server-Anwendung (wo es dann
also ebenfalls
um Serveranwendungen ginge) nichts im Wege. Ich sage also mal:
beides

Kannst du den Zweck der Appllikation grob umreiszen? Ich kann mir da nicht so recht etwas drunter vorstellen…

Ich merke in kleineren Applikationen die Trägheit
der UI von Java im
Vergleich zu anderen Sprachen (die WindowsForms nutzen, oder
aber auch QT o.ä.)
schon recht deutlich, und befürchte eben nur, dass sie in
größeren Anwendungen
noch zunehmen könnte.

Das bezieht sich aber nur auf die mitgelieferten AWT-Klassen, welche, zugegebenermaszen, in der Tat einige Maengel diesbezueglich aufweisen. :frowning:

Gluecklicherweise ist man ja nicht auf diese beschraenkt. =)

Hast du mal mit Eclipse gearbeitet? Eine wirklich schoene Mehrzweck-IDE, fuer welche eine eigene UI library entworfen wurde, die ebenfalls als open source zur Verfuegung gestellt wurde ( http://www.eclipse.org/swt/ ). Ich empfehle dir, eclipse einmal runterzuladen und auszuprobieren. ich benutze diese IDE zum Programmieren in Java, und habe bei diesem Programm, das ja im Grunde aus nichts Anderem als einer komplexen Oberflaeche besteht, nie Traegheits-Probleme gehabt.

Solange man sich von AWT (und damit von Swing, und allem anderen was darauf basiert) fernhaelt, ist dieses Problem viel weniger gravierend als es auf den ersten Blick scheint.

#14

Kannst du den Zweck der Appllikation grob umreiszen? Ich kann
mir da nicht so recht etwas drunter vorstellen…

Es ist eine Dealer-Management-System für Autohäuser. Alles, was an
kaufmännischer Tätigkeit in einem Autohaus anfällt, ist mit unserer Software zu
erledigen. Es arbeiten alle Mitarbeiter in einem Autohaus mit dieser Software
und erledigen Aufgaben wie Stammdaten, Dispo, Werkstatt, Verkauf, FIBU…

Hast du mal mit Eclipse gearbeitet?

Schon seit zwei Jahren. „klickst Du noch, oder entwickelst Du schon?“ *g*

[…] fuer welche eine eigene UI library entworfen wurde

Ja, mit SWT habe ich auch mal ein paar simple Oberflächen zusammengeschraubt.
Aber noch nie ernsthaft etwas damit angefangen. So ganz stimmt das mit der
Sorglosigkeit dort aber auch nicht. Denn unter Linux ist auch diese Oberfläche
träge. Das liegt dann aber wohl eher daran, dass die langsamere GTK- anstatt
die schnellere (leider unter einer nicht kompatiblen Lizenz liegenden)
QT-Bibliothek benutzt wird. Aber Du hast vielleicht Recht, dass es damit unter
Windows flüssiger zugehen könnte. Das werde ich mal mit bedenken. Danke für den
Hinweis!

Gruß

#15

Alles, was an
kaufmännischer Tätigkeit in einem Autohaus anfällt, ist mit
unserer Software zu
erledigen. Es arbeiten alle Mitarbeiter in einem Autohaus mit
dieser Software
und erledigen Aufgaben wie Stammdaten, Dispo, Werkstatt,
Verkauf, FIBU…

mysql zentrale server-applikation, welche neben dem Daten weitergeben noch Termine prueft und meldet, usw, usf client-applikation

Laesst sich doch alles sauber realisieren, voellig ohne Aufwand dank Serialisierung :smile:

Schon seit zwei Jahren. „klickst Du noch, oder entwickelst Du
schon?“ *g*

)

Aber Du hast vielleicht Recht,
dass es damit unter
Windows flüssiger zugehen könnte. Das werde ich mal mit

Nunja, es ist ja vorher bekannt, unter welchem System die Software laeuft, oder?

#16

In unserem Fall ist es so, dass länger andauernde Prozesse
(suchen, kopieren,
konvertieren …) in solche Threads ausgelagert werden sollen,
damit die
grafische Oberfläche nicht ‚einfriert‘.

wie schon oben erwaehnt:
mysql server-layer in java client-layer in java

Damit laesst sich so gut wie alles, was nur Datenverarbeitung angeht, auf den server-layer auslagern, und die Clients fragen nur ab was sie interessiert, bzw geben Befehle was zu passieren hat, ohne wirklich beteiligt zu sein.
Wenn man dann dem Server-Layer ordentlich Rechenleistung verpasst, hat man ein sehr stabiles und unabhaengiges System.
Ganz abgesehen davon loest das viele Threading-Probleme, die entstehen wenn von mehreren Systemen auf eine Datenbank zugegriffen wird, da dies ja alles xentral geschieht.

Viva OOP :smile:

#17

mysql zentrale server-applikation, welche neben dem
Daten weitergeben noch Termine prueft und meldet, usw, usf
client-applikation

Laesst sich doch alles sauber realisieren, voellig ohne
Aufwand dank Serialisierung :smile:

Ja, schon klar. Darüber, wie das in Zukunft vonstatten gehen soll, hab ich
schon ein paar Rohideen im Kopf. Man kann so eine Software allerdings nicht mal
eben umstellen. Das bedarf etwas längerfristiger Planung, weil wir hier von
etwas größerem als einen Terminkalender reden *g*. Das ist ja auch nicht mein
Problem gewesen. Eher, mit welcher Sprache dies in Zukunft passieren sollte…

Aber Du hast vielleicht Recht,
dass es damit unter
Windows flüssiger zugehen könnte. Das werde ich mal mit

Nunja, es ist ja vorher bekannt, unter welchem System die
Software laeuft, oder?

Ja, zu 99.999 Prozent unter Windows (leider Gottes *g*).
Ich glaube ich wäre der Erste/Einzige (bis dato), der es nicht unter Windows
einsetzen würde. Also sind wir nur Windows orientiert

#18

Ganz abgesehen davon loest das viele Threading-Probleme, die
entstehen wenn von mehreren Systemen auf eine Datenbank
zugegriffen wird, da dies ja alles xentral geschieht.

Hmm, kannst Du mir das mal geneuer erklären? IMHO _solltest_ Du für jede
SQL-Transaktion eine eigene Verbindung zu der Datenbank besitzen. Mit anderen
Worten:
x Benutzer
y vorgehaltene Verbindungen (Y >= X)
y Threads auf der Datenbank aktiv

Dabei spielt es keine Rolle, ob all diese Verbindungen durch den Server
gehalten werden (Connection-Pooling - wie von mir dargestellt), oder ob diese
durch verbundene Clients zustande kamen. Wichtig ist halt nur, dass man eine
Verbindung nicht für mehrere Benutzer verwenden _sollte_.
Kann ja, sollte nein

Oder hab ich Dich missverstanden?

Grüsse