#13 Losing entries in the .cfg file

When the flooder is succesfully screaming along banging
a form, occasionally it trips over itself wiping out custom
HANDLE- entries and starts displaying

nullcreditcards.txt not found

or

nulldomains.txt not found

etc etc

Checking the .cfg file shows that most of the HANDLE-
entries have been removed accidently. I'm wondering if
this is because the .cfg file is being opened more than
once and one set of changes is lost by the other file
access?

[Anonymous]

Logged In: YES
user_id=924512

The reason the nulldomains.txt part appears is because the
DataDir= entry gets wiped out.

[Greg Letiecq]

Logged In: YES
user_id=913401

Need to implement threadsafe locking on file operations. This can
probably be handled by adding "synchronized" to method
declarations for the formflood properties class.

Thanks for catching this.

[Nobody/Anonymous]

Logged In: NO

You could probably avoid the need for locking at all if you
make the configuration permutable, much like Java's own
String class.
Make a config and or a filereader class and whenever you
spawn a new thread, pass a reference to this one instance
class on, thus removing the need to have file operation in
each instance.
I.e:
nextThread = new Instance(configClass, dataFileReaderClass);
then in Instance code:
form.data = dataFileReaderClass.getData("company");

This can cause a bit of overhead so you might want to do
some profiling.

As an end note, beware that declaring a function
as "synchronized" to threaded classes does not solve locking
issues alone, you need correct locking and thread.wait() to
ensure locking. Otherwise you still risk lost updates, dining
philosophers or dirty reads.

MERLiiN