Application Cross-talk in a wireless environment

[sybs01]

Re: Application Cross-talk in a wireless environment

Hi Rob,



See my tips on Alpha Five Record Locking here. I surmise that the less than perfect wireless connection is breaking the process of locking, a crucial aspect when not using True client-server. One thing to try is to use the wireless utilities (typically come with the NIC cards and/or windows) and see what other networks are in the immediate area, and then change to a less used channel.

An alternative to wireless is a Powerline adapter that feeds ethernet through the AC wires. My experience is that they are very reliable in many typical offices.

Ira, you rock

This is EXACTLY the type of thing I was fearing (yet hoping against hope wasn't the case), because I've also just addressed the thing with Atomic writes and realized that (assuming otherwise was a big brain f@rt on my part) transactions are unsupported.

I had Ass-u-me'd that alpha supported the concept of commit rollback natively because of their support for SQL and only just found out that, in fact this is not the case. Of course, I tested this app without the benefit of extra simultaneous testers, so was surprised that my cancel at the parent level did not drill down to the child level; i.e. a parent save could not be roll-back once and embedded child add took place.

My only confusion came because , connecting "wired" the additions worked.

Good to find out now. To affect such changes going forward, I'm designing systems with a "Temp" set,, then using Xbasic to make the "adds" only upon pressing a "save". Probably the delay in a wireless setting is causing the "lock" to become confused - the wired is quicker and works - the wireless is delayed and doesn't.

I'll let you all know how it turns out.

BTW, I'm going to add transactions to the "wish list," although I feel for the Alpha group, where they have to juggle the simplicity of the current setup with a more sophisticated approach that comes with Atomic writes.

P.S. Ahh. Wish I had seen the link earlier - your understanding of atomization is the same as mine. I feel like a bonehead for not realizing this earlier. Oh Well, Live and Learn!!

[sybs01]

Re: Application Cross-talk in a wireless environment

Ira, et al,

The information from your link should be viewed as INVALUABLE to anyone developing a networked, multi-user, scalable application. I've added it to my "Alpha 5 bible" � it even perhaps should be added to the �documentation". I would imagine that most, if not all, issues with scalability and response times in an enterprise (an IT snooty term I dislike, but it aptly describes the different arenas) environment would be at least partially explained by this.

Example: I oversaw the development of an application, using a Sybase 10/Power Builder Client/Server stack, that was elegant and powerful - until you started scaling to it to +30-40 users, and then went into the dirt. The explanation ended up being Sybase�s use of a concept called �Page locking", where "pages", or blocks, of data were locked rather than locking at the "row" level, was the culprit - we wound up moving to Oracle. (As an aside, MS SQL Server 6.5, I believe, was built from a license of Sybase - go figure).

If multiple records, or rows, happened to occupy the same block, they were locked along with the one actually being used. The upshot was, as users were added, so was the likelihood that records being added/changed by two or more users might occupy the same block and were already "locked", exponentially degrading response times.

Point being, locking has a potent effect on performance.

My current application is deployed in a small environment - only three to five users are adding at the same time. However, the concept is ALL of them are "appending" at the same time to the same set. I developed heavily in the Alpha 4 arena and remember eschewing "set adds" - i.e. adds similar to standard invoices, like the ones in the invoice in the Alpha Sport Invoice form app, where there is a parent/child relationship to a header and line items. I would refrain from using more than one table as the target for adds. I thus incorporated as many line items as possibly needed and combined the Header/line items into one table. I also would not do sub-forms for additions.

This violates DB normalization concepts, but made multi-user networking in a dBase dialect much simpler. My mistake here was assuming that, because it offers SQL support, Alpha had incorporated record locking/"atomic" rollback-commit into its DB Set architecture.

Of course, it doesn't. This is the fine line that separates "simple - easy" from "enterprise". This must be a huge conundrum for the Alpha folks. It would seem that (as evidenced by the SQL/AJAX concept) they are treading this fine line.

So, to wind up my "light bulb going off" moment, we may need, as a development group, or Alpha as a solutions provider, to define a set of standards to guide in this area.

I'm working on a scratch re-write of an application I've had running at a client in Alpha4 (15-20 users) for almost 20 years (originally version 3-4, circa '91) that, especially since XP, has had great user interest to migrate, but less funding. I'll be looking at how to incorporate SQL commands to support commit/rollback, Virtualization, etc., so I will keep the group apprised of progress, as well as probably asking lots of questions. (Whatever travails I encounter, this�ll be tons easier than .net or PHP).

BTW, I just purchased Martin Heller's book - any thoughts?

This is a fabulous group, as evidenced by this post's response, and I thank everyone for their input.

[aRob]

Re: Application Cross-talk in a wireless environment

Well I never saw this bizarre twist coming.

'Record locking'? Really?? Obviously very application specific but how would that work in this case? Or rather not work in this case?

I must have misunderstood this statement:

when simultaneously entering data into the Alpha5 application on two machines, data from one appears in the other, then locks the one of the machines

Just curious.

[csda1]

Re: Application Cross-talk in a wireless environment

Hi Rob,

Well I never saw this bizarre twist coming.

'Record locking'? Really?? Obviously very application specific but how would that work in this case? Or rather not work in this case?
....
Just curious.

The full quote was

....the customer has reported that, when simultaneously entering data into the Alpha5 application on two machines, data from one appears in the other, then locks the one of the machines.

The operative words here being "Customer reported". Depending on the customer, the interpretation and timing of what they saw leaves a lot of questions as to exactly what was really seen and what was happening.

The key to a solution is the fact that a hard wired network works reliably.

That makes the wireless network communications as the culprit (for whatever reason).

One bad network packet that looks good (in terms of the error correction) can quickly toast an application. Probabilities are generally small, and most network packets that are bad are resent, but the more packets and the more network retries to send a packet, the higher the risk. It only takes 1 bad packet out of billions over time to bring down the application when not using true client-server.

Incidently, it also takes only 1 alpha particle (as in random cosmic particles) to corrupt a key memory location, or other electronic gate, and bring any computer crashing too! It actually use to be a big problem in the late 1980's as electronics got smaller and technology did not protect this as much. It's gotten better, but it's not perfect.

Since the wireless network was in question here, the problem "points to" being manifested in a locking issue and/or a packet being interpreted for the wrong IP address. However, it could have also potentially stored invalid data if that was what the network packet was carrying (and you won't notice it until somebody looks at bad data of a record).

The trouble is, it is really hard to replicate consistently to capture these problems and to know, and the customer report could be more precise to help analyze it.

The point of the locking tips is to show how one computer can lock an entire network application if not true client-server, and how communications over the network is happening with Alpha 5 native databases.

[aRob]

Re: Application Cross-talk in a wireless environment

Ira,

Two people doing data entry are not going to generate billions of packets. If the network connection is so poor that a huge mass of packets is being resent because of errors, then the customer would complain about performance issues first. The application would be unusable.

Also no complaint about garbled characters on screen.

I also see 'wireless network communications as the culprit (for whatever reason)'. But I don't see how record locking fits into it.

[csda1]

Re: Application Cross-talk in a wireless environment

Hi Rob,

Two people doing data entry are not going to generate billions of packets. If the network connection is so poor that a huge mass of packets is being resent because of errors, then the customer would complain about performance issues first. The application would be unusable.

On a network, everybody gets a turn, so re-sends of data will not necessarily bring performance down for other workstations, but it definitely could, depending upon where the failing point is, e.g. workstation NIC card, cable/wireless to router, router, cable/wireless (not that you should EVER have wireless to a server) to server , server NIC card etc.

I don't know if it's millions, billions, or whatever. It only takes one. I've seen in one actually case it took a week to toast the network with 1 bad packet that got through. But work the numbers. If you do a non- LQO query of 100,000 records, that's probably responsible for 250,000+ packets of info. Some Network gurus with the tools are welcome to supply any real numbers here if they can from running some tests. 4 queries would reach a million. 4000 queries (a lot, I'd agree, for a day, but certainly doable in 2 weeks in some offices manually), would have to be generated probably by code to do it in a short time.

Also no complaint about garbled characters on screen.

They would only see it if they were looking at the records that the bad packets might have written to (which may not be the active record) because an address to a location in the file may have been corrupted in the packet.

I also see 'wireless network communications as the culprit (for whatever reason)'. But I don't see how record locking fits into it.

That they had some type of locking issue points to a lock problem, but not the source of the problem (which we both agree is the wireless).

File/record locking and index file retrieval packets probably account for the major amount of Alpha 5 network packets, so I wouldn't be surprised if a network error manifests itself as a locking issue, or, due to a bad index retrieval, an incorrect record being read or write.