Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Question about entire picture. Please join it

Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd like to discuss the entire server architecture of this project. I've read a lot of ideas, approaches and some of them controvert others so I need your participation to dot one's iii.
1. Changing/extending Dada class.
I create an interface DataIfc that includes all public methods of Data class and three additional methods (lock, unlock, criteriaFind). From Data class I remove empty methods lock and unlock. I create a new class DataEx that extends Data class and implements DataIfc. In DataEx I implement lock, unlock and criteriaFind. To implement criteriaFind I don't use StringTokenizer but rather use own machine-state algorithm.
2. RMI, threading, lost connections
I use RMI (since it's much easier and a lot of common functionalities are done). I create an interface ConnectionFactoryIfc that has only one public method getConnection() returning DataIfc. Next I create two implementations of this interface: LocalConnectionFactory and RemoteConnectionFactory. In case of local database getConnection() returns DataEx object. In case of remote connection RemoteConnectionFactory not only implements ConnectionFactoryIfc but also implements java.rmi.Remote and registers in RMI. Its method getConnection() returns new RemoteData object that extends DataEx and implements java.rmi.Remote but doesn't register in RMI. Here we achive incapsulation of the system that RemoteData might be gotten only through getConnection() method. Since RemoteData is a remote object I implement java.rmi.server.Unreferenced interface that will help to detect wich 'clients' lost connection.
3. Lock/Unlock
DataEx has a Map that maps Integer (record number) to "client's" ID. As this ID some composite value may be used (object's hash code + creation time or whatever). Since each DataEx's oebject has its own ID and knows it I don't need to change signatures of lock/unlock methods. The question is when to call this function? Obviously in booking process (as said in the spec. lock/read/modify/write/unlock, btw what they mean by write() method?). But should normal reading/writing process be wrapped by lock/unlock? I don't know. It seems to me yes, 'cause if user A locks rec. 1 in the DB to book and user B modifies this record what's the idea of such a locking? According to the spec. we don't have to implement on the client side anything except for searching and booking but there is another clause in the spec. about expectation of future functionality. But if we wrapp getRecord and modify() wouldn't it be overkill? Your ideas?
So I think in the beginning of book() function lock() is called and at the end of book() unlock() is. There are several ways to do synchronization on the specific record. The simpliest one is to synchronize on tha Map itself. Lock(int recNo) detects if recNo exists in the Map and if corresponding owner differs from the object's ID where Lock is executing function wait() is called. In each unlock() function notifyAll() is called and every stacked thread has a chance to detect existance its recNo in the Map. May be this approach is a bit rude but it looks simple. your suggestions?
Well, my question becomes a project documentation:-) Let's start discuss it together and may be some pitfalls appear.
[ January 06, 2002: Message edited by: Roman Rytov ]
Consider Paul's rocket mass heater.
    Bookmark Topic Watch Topic
  • New Topic