Have a table where you have 1 row that marks the relationship between two 
clients. Like a cartesian product:
   
  A, B
  A, C
  A, D
  B, A
  B, C
  B, D
  ..and so on.
   
  Have all clients have their dedicated connection acquire locks on these rows. 
Each lock represents a client that may post a message.
   
  Have all clients have 1 connection per potential message source client. Have 
each of these connections attempt a commited read on respective row on separate 
threads. 
   
  For example, A will have a connection waiting on row B->A, another connection 
on C->A, etc. 
   
  When B posts a message to A, it will insert it into messages table and it 
will release it's lock on B->A row (and B->C, B->D etc) in the locks table. 
This will cause A's lock waiting connection to return the result which 
indicates B posted a message. Within this thread (of A), you need to read 
messages table with a repeatable read and before you release that repeatable 
read lock, A needs to start waiting on lock B->A again, so that B does not post 
another msg to A while A is not looking. But for this to happen, B must have 
locked B->A by now. When should B lock B->A again? I dont' know yet. Figuring 
that out is left to the reader as an exercise. LOL. (Please let me know if you 
make this work)
   
  Better have a row version that is incremented per row in the messages table 
so that you read only after that level and keep it as current client version to 
use as water mark until next time.
   
  This is alot of total connections but if you got enough memory, it should 
work. I did not try this, there may be problems when you actually try. Lock 
escalation may cause problems. Maybe Derby has a way to disable lock 
escalation. You may be able to reduce number of connections by thinking in a 
smarter way to maintain your locks via persisted state info in another table(s).
   
  JMS might be easier and use less threads with async io.
   
  Regards,
  Ali
   
  
Kurt Huwig <[EMAIL PROTECTED]> wrote:
  Forget about Derby for chat and have a look at JMS. This is a good 
implementation:

http://joram.objectweb.org/

Am Mittwoch, 13. Februar 2008 schrieb musky:
> also i dont want to use any sockets.
> all the chat clients connect to the database server.
>
> musky wrote:
> > i want to use derby as a chat server,
> > my idea is to insert whatever a user types into a table in the
> > database.This table can have two fields UserID and the
> > message(VARCHAR).how do i convey the inserted message to the other
> > party??
> >
> > please help.
> >
> > thanks.



-- 
Mit freundlichen Gr��en
........................................................................................................
Kurt Huwig - Leiter IT-Abteilung

www.scooter-attack.com
IT Park Saarland | Altenkesseler Str. 17/C1 | D-66115 Saarbr�cken
Phone: +49-(0)-681-9762-371 | Fax: +49-(0)-681-9762-373

Aktuelle News: www.scooter-attack.com/news/
need for speed? ... amphetamine your engine!

HRB 12678 Saarbr�cken | Gesch�ftsf�hrer Magnus K�pfer, Thilo Nast


       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.

Reply via email to