db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suavi Ali Demir <dem...@yahoo.com>
Subject Re: Using derby as a chat server
Date Wed, 13 Feb 2008 21:54:35 GMT
Have a table where you have 1 row that marks the relationship between two clients. Like a cartesian
  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,
  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.
Kurt Huwig <kurt@scooter-attack.com> wrote:
  Forget about Derby for chat and have a look at JMS. This is a good 


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

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.
View raw message