SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Originally posted by Nicholas Cheung:
...
How should I interpret it?
1. Only 1 thread can access the file at one time even with multiple requests?
OR
2. Multiple requests can call same read (for example) method, and they worked concurrently?
...
then, this results in an inconsisent read!!
Sun Certified Java Web Component Developer for J2EE v1.4<br />Sun Certified Java Developer for J2SE v1.4<br />Sun Certified Java Programmer for J2SE v1.4
SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Originally posted by Nicholas Cheung:
...
1. Do I need to handle dirty read?
i.e. When a thread writes to record X, while another thread reads the record X. Should I prevent this?
2. I read some previous posts that the system has a "DATABASE LOCK", which locks the whole DB file. Should I need this? (in order to prevent dirty read/write)
3. If I have a wrapper class, say RecordHandler.
It has the same method as what defined in Data.java as well as DBMain.java (the interface given by Sun), but I put the keyword "synchronized" in front of each function, does this suitable? or it violates the spec.
Sun Certified Java Web Component Developer for J2EE v1.4<br />Sun Certified Java Developer for J2SE v1.4<br />Sun Certified Java Programmer for J2SE v1.4
I myself extended DBMain to include another operation and then had Data.java implement an ExtendedDBMain interface instead. This should still allow my Data class to be tested by Sun's auto-test procedures because the the class will still adhere to the interface (functionality) of a DBMain object.
SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
Originally posted by Bharat Ruparel:
...I needed at least one more public method, I called it getColumnNames, in the Data class however, to get the column headers for the UI. To accommodate it, I ended up creating another interface I called DBMainExtended (you call it ExtendedDBMain, same thing really). DBMainExtended is implemented by the DataAdapter class in my implementation and not the Data class...
Sun Certified Java Web Component Developer for J2EE v1.4<br />Sun Certified Java Developer for J2SE v1.4<br />Sun Certified Java Programmer for J2SE v1.4
Do you suggest that I keep my Data class implementing the DBMain interface only and move the "extra implementation code" of my ExtendedDBMain interface to my DataAdapter class?
SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
Sun Certified Java Web Component Developer for J2EE v1.4<br />Sun Certified Java Developer for J2SE v1.4<br />Sun Certified Java Programmer for J2SE v1.4
1. Use a single instance of the file-pointer doing read/write instead of multiple pointers, and
2. Synchronize the read/write operations to the file so that an ENTIRE record including the delete flag is read/written in one fell-swoop.
SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |