[SATLUG] LAMP Server Question #4
alesmerises at satx.rr.com
Wed Oct 8 23:36:17 CDT 2014
These are all good points. They touch on a number of details I should
remember to consider. Thanks.
Many of these won't be a problem due to the small scale and the limited
number of users the database will have to support. I do know that I
will have to deal with rollbacks, especially since it seems as their
network connectivity can be a little unreliable. I had heard about the
'deadly embrace' problem before, but it does bear repeating -- it's
something that could easily be overlooked.
Fortunately, I will only have to have one database to deal with, so I
won't have to worry about the extra complexity of two phase commits.
And again, since I am dealing with only a limited number of users and
data volumes, I think PHP will be more than sufficient for the job.
As for open source equivalents to Dreamweaver, is anyone on the list
familiar with any of them where you can make any recommendations (pro or
On 10/8/2014 10:40 AM, Stewart Smith wrote:
> Answering a question with a question, are you doing a transactional database?
> If so, you need to remember that you have to code for rollback recovery of partially completed transactions. HTML is stateless.
> In high volume transactional databases you get into he problem of deadly embrace, two transactions each locking a different data element that the other needs. You need to make sure this problem is treated.
> Will you be updating more than one database in a transaction? If so, you need to consider the problem of two phase commit.
> Sadly, this points in the direction of transaction processors. Tuxedo and JBoss or their open source equivalents.
> Dreamweaver is the commercial standard in professional Web development, but there are open source alternatives.
> Depending on the volume of the transactions, you might gain something from considering something other than the "P" in LAMP being PHP. Python comes to mind. Further, don't dismiss C, if the transactions are bogging down.
> One final note. If you are doing something like a catalogue order entry application, where there will be a great deal of graphic data served in addition to high transaction volume, you might want to consider offloading the graphic serving to another machine that does only that.
> Sorry for the all over the place answer. If these things get big, they can create some interesting problems.
>> Date: Tue, 7 Oct 2014 22:48:57 -0500
>> From: alesmerises at satx.rr.com
>> To: satlug at satlug.org
>> Subject: [SATLUG] LAMP Server Question #4
>> I am working on a project that involves setting up a server for a
>> customer where they will need to access a database on an on-going basis
>> for various kinds of record-keeping, etc. I have come to the conclusion
>> that a LAMP server will be the best solution for them (I won't bore you
>> with all the reasons why, but let's assume that is the way I will go).
>> This will be the first time I will undertake a project quite like this,
>> so I have a few specific questions where I would like some opinions,
>> especially the professionals out there who may have done jobs similar to
>> this for paying customers.
>> Since the questions deal with different topics, I will send them out
>> separately so as not to muddy the waters by mixing things together.
>> --> QUESTION #4:
>> What tools / software recommendations do you have for the PHP coding &
>> web page development would you recommend? I'd prefer something that
>> runs in the GUI so that I can get quick and easy feedback about layout,
>> etc. to speed-up the development process.
>> Al Lesmerises
>> SATLUG mailing list
>> SATLUG at satlug.org
>> http://alamo.satlug.org/mailman/listinfo/satlug to manage/unsubscribe
>> Powered by Rackspace (www.rackspace.com)
> SATLUG mailing list
> SATLUG at satlug.org
> http://alamo.satlug.org/mailman/listinfo/satlug to manage/unsubscribe
> Powered by Rackspace (www.rackspace.com)
More information about the SATLUG