Designfrage, DB und Threads

[Tallan]

Hallo zusammen,

folgendes ist im groben geplant, Zahlreiche Clients die über eine Serverapplikation zugriff auf eine Datenbank nehmen.

Meine Frage ist welchen Teil des Servers ich was das Design anbelangt am besten in Threads unterbringen soll.

Meine Erfahrung diesbezüglich ist noch sehr gering, bisher dachte ich an Folgendes :

Client sendet Befehle an den Server
Server verifiziert den Client
Server startet einen Thread mit der Anfrage an die DB und der rückantwort an den Client.
Thread wird wieder geschlossen.

 

[Michael...]

Zielt Deine Frage auf was bestimmtes ab? Prinzipiell brauchst Du für jeden Client einen Thread in dem der Server auf deren Anfragen wartet.
Die Serveranfrage an die Datenbank kann, muss aber nicht in seperaten Threads laufen.
Musst halt aufpassen, dass der Client nicht ungeduldig wird und mehrmals hintereinander die gleiche Anfrage stellt.

 

[Tallan]

Zielt Deine Frage auf was bestimmtes ab? Prinzipiell brauchst Du für jeden Client einen Thread in dem der Server auf deren Anfragen wartet.
Die Serveranfrage an die Datenbank kann, muss aber nicht in seperaten Threads laufen.
Musst halt aufpassen, dass der Client nicht ungeduldig wird und mehrmals hintereinander die gleiche Anfrage stellt.

Es geht mir darum wie ich soetwas am "saubersten" löse, also z.b die jeweils einezelnen anfragen in einen thread zu packen oder z.b. einen permanent laufenden thread für jeden client schaffen.....

 

[MrWhite]

Wieso einen eigenen Server schreiben? Warum nicht einen Application-Server nehmen der dir die Kommunikation abnimmt? Brauchst ja nicht zwangsweise ueber http kommunizieren, wenn du den overhead scheust.

Was du vorhast hoert sich fuer mich stark nach einen WebService Szenario an. Schonmal Apache Axis 2 angeschaut?

 

[maki]

Webservices um Java Clients mit Java Servern kommunizieren zu lassen ist nicht gerade eine effiziente Lösung...

Ansonsten gibt es da RMI, Spring Remoting, EJBs. etc. pp.

 

[Tallan]

Wieso einen eigenen Server schreiben? Warum nicht einen Application-Server nehmen der dir die Kommunikation abnimmt? Brauchst ja nicht zwangsweise ueber http kommunizieren, wenn du den overhead scheust.

Was du vorhast hoert sich fuer mich stark nach einen WebService Szenario an. Schonmal Apache Axis 2 angeschaut?

nein ganz und garnicht es handelt sich um ein clientprogramm das per rmi vom server daten anfragt.

 

[MrWhite]

Naja, in dem Fall:

Fuer jeden Client einen Thread zu erstellen kickt deinen Server bei vielen Clients in Nirvana. Verwende zumindest einen ThreadPool und lasse den Client warten bis was frei wird.

Daumenregel fuer gute Performanz unter win32 war AnzahlThreads=Cores*8 oder Cores*16 iirc, wobei das stark abhaengig von der Plattform ist.

 

[Tallan]

Naja, in dem Fall:

Fuer jeden Client einen Thread zu erstellen kickt deinen Server bei vielen Clients in Nirvana. Verwende zumindest einen ThreadPool und lasse den Client warten bis was frei wird.

Daumenregel fuer gute Performanz unter win32 war AnzahlThreads=Cores*8 oder Cores*16 iirc, wobei das stark abhaengig von der Plattform ist.

dann würde ich also besser für die einzelnen transaktionen bzw methodenaufrufe threads benutzt, die sind ja sehr schnell wieder beendet?!

 

[MrWhite]

Ich bin kein Experte auf dem Gebiet aber:
RMI hat doch per se schon ein Pooling, oder tauesch ich mich da? Was musst du dich dann ueberhaupt noch um solche Geschichten kuemmern?

RMI sollte doch einfach ein POJO aus dem Pool holen, deine Methode ausfuehren und fertig. Wieso musst du dich noch um solche Geschichten kuemmern? Wenn die Datenbankzugriffe hier das Bottleneck darstellen, dann nimm einen Threadpool und lasse deine Workerthreads die Abfragen nacheinander abarbeiten.