How to circumvent client-side locking?

[Christian Garcia]

I designed my FlightModel class to serve as an adapter for an instance of the Data class. FlightModel provides the same functionality regardless of whether the "data" instance held within is created on the local machine (DataExtension) or returned by an RMI request (RemoteData).
My dilemma is that I cannot find a solution that will enable my code to circumvent the locking process that occurs when reading/writing/modifying the database when the Data instance resides on the local machine. The reason for this being that the adapter methods of the FlightModel are atomic regardless of the location of the Data instance.
Now, I could add conditional logic to check an "isRemote" flag that's tripped when an instance of RemoteData is returned. When this flag is false, the code would delegate to non-locking code that performs the read/write/modify actions. To me, this seems an ugly way getting around the locking issue.
Has anyone experienced this and/or successfully designed around the issue?

[Andrew Monkhouse]

Hi Christian,
Why do you want to circumvent the locking in local mode?
I can understand the opposite argument: if you currently dont have any locking in local mode, you don't really need it, so you may not want to code for it.
But if you already have locking working in local mode, then why not leave it alone? What is the downside? I could even argue that from a mainenance point of view, it is easier for someone to maintain code if the locking is always happening, rather than the maintainer needing to determine what mode they are in.
Regards, Andrew

[Christian Garcia]

Andrew,
I agree with your comments 100%. I went over my code last night for quite a few hours re-analyzing the design. I came to the conclusion that having locking/unlocking occur on a local database shouldn't impact performance. Your point:

I could even argue that from a mainenance point of view, it is easier for someone to maintain code if the locking is always happening, rather than the maintainer needing to determine what mode they are in

falls in line with the existing implementation of my code.
Thank you for your input.