Win a copy of Modern JavaScript for the Impatient this week in the Server-Side JavaScript and NodeJS forum!

Kerim Kara

Greenhorn
+ Follow
since Aug 20, 2014
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
2
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Kerim Kara

welcome
and What aspects of MongoDb should be enhanced ?
or
do you think that there is a scenario that MongoDb should not be used ?

Thanks
Regards

4 years ago
did you have a chance to benchmark Java 8 FP and/or Scala performance...

if there is , apart from Tail recursion call , what other elements in Java 8 contribute to performance difference with Scala

Thanks
4 years ago
Do you think java can provide same functionality with Scala ?

or do you think java is going to become fully functional language not just adding one feature

Thanks
4 years ago
Hi Venkat

java 1.8 functional programmin capabilities are limited to other languages like Scala or Lisp.
do you think java 1.8 is efficient as others ?
5 years ago
What do I need to know for the exam required for certification?

is technical information needed except from knowledge of project implementation ?

and what should be the detail level of user interface documentation, choices.txt and javadocs ?

Thanks
Do we need to display all records in server mode ?
if so I am planning to use rmi connection to server after server is started ?
should I use something else ?
Thank you again Roel.

Roel De Nijs wrote:

Kerim Kara wrote:By the way I am using thread ids for locking not client id, I think I need to change that.


That's an easy one: if you use RMI, you can NOT rely on thread ids. Because there is no guarantee that subsequent requests of the same client are handled by the same thread.



I think it is better to set client ip to thread name and use thread name for lock check

I think it comes to point how you perceive Data.class. it should be used by both server and standalone modes.

lock() method should be called outside of the Data.class, I totally agree on that. But to execute update regardless
of mode , you must call lock() outside of update() method, which is sharing of some responsibility of update method in my opinion.
isn't it better to preserve atomicity of method by giving the responsibility of locking to caller by exposing lock method to caller ?

By the way I am using thread ids for locking not client id, I think I need to change that.



and Roel Thank you for taking time to explain and respond promptly. I'd really appreciate that .

Roel De Nijs wrote:
So in the update method you need to verify that the client who is updating this record was the client which locked the record (to prevent clientB from updating a record locked by clientA). But how will this check succeed in standalone mode, when you don't call the lock method



how many client can you create in standalone mode ?

it is the running client and that's all(no rmi) , isn't it ?
no I was thinking 2 service classes one calls data.lock before data.update /delete an the other one just calls data.update

Roel De Nijs wrote:
And if your must-to-implement interface states you have to call lock before being able to update/delete a record



my initial thought was it is not saying a lock a record for update each time, just saying make only one client edits that which is implicitly achieved in standalone mode.

Roel De Nijs wrote:

Kerim Kara wrote:I will keep calling lock/unlock method in only rmi server


Then you'll be violating a must requirement. Because the interface you MUST implement clearly states for the lock-method:

instructions.html wrote: // Locks a record so that it can only be updated or deleted by this client.


So before you can update/delete a record, it must be locked! It doesn't matter in which mode your application is running in.



what I understand,(probably wrong but still) from above instruction statement is record(given record id) can be updated or deleted by one client at a time.

Do we really need to use locking at which there is implicitly only one client in standalone mode?
Thanks to both you guys.

I'd prefer to merge Data.class functionality with Rmi server functionality and keep the database object with separate update delete find methods.
But since data class is a must for both server and standalone mode, I will keep calling lock/unlock method in only rmi server and
data class will be an interface accessing database.
still though, why do we need locking method in single threaded environment in standalone mode ?
we lose some performance because synchronization and thread safety code in standalone mode.

is there a explanation for that one or am I missing something

Thanks