Re^2: Migrating Perl to Java or .NET

I should clarify...

Yes, I certainly don't want to dubplicate code. There are many modules (here "module" means functional subsystem from the user's perspective). E.g. imagine 6 different people see the tickets and do different things with them. They each get a slightly different view and focus on different parts of the ticket data. 3 modules are done in Perl. We would want to do modules 4-6 in Java or .NET and then go back and one at a time convert modules 1, 2, and 3 to the same technology.

It sounds like this is doable as long as all state is maintained in the database, right? We do maintain session state while fields are being modified, but as long as no two people access the same ticket at the same time it should be ok; even then it's just the usual data concurrency/overwriting issues, and won't cause any type of server state inconsistency (as opposed to potential data inconsistency).

--Jason

Comment on Re^2: Migrating Perl to Java or .NET

Replies are listed 'Best First'.
Re^3: Migrating Perl to Java or .NET by polettix (Vicar) on Mar 24, 2005 at 18:00 UTC
Keeping all data (including state) in the DB allows you to develop manipulation programs in whatever language you like. Concurrency will be handled by the MySql server process, so it won't be an issue to you for what server state consistency is concerned. As for data consistency, you really have to dig into your code looking and take countermeasures regarding possible critical races in UPDATEs. This could be achieved with a custom "locking" mechanism (via an added column, for example), but understand that a lock by a program which is about to die makes the locked data "read-only" virtually forever. Another quick solution would be replacing UPDATEs with REPLACEs. Flavio Don't fool yourself.	[reply]

Replies are listed 'Best First'.

Re^3: Migrating Perl to Java or .NET
by polettix (Vicar) on Mar 24, 2005 at 18:00 UTC

manipulation programs

As for data consistency, you really have to dig into your code looking and take countermeasures regarding possible critical races in UPDATEs. This could be achieved with a custom "locking" mechanism (via an added column, for example), but understand that a lock by a program which is about to die makes the locked data "read-only" virtually forever. Another quick solution would be replacing UPDATEs with REPLACEs.

Flavio

Don't fool yourself.

[reply]