an into to web development building applications that target browsers requires a little effort...

An into to Web development

Building applications that target browsers requires a little effort

learning, but the results are quite worthwhile

By Roger PenceASNA Product Evangelist

Integrating your IBM i with Web, Mobile, and Windows © 2013 by ASNA. All rights reserved. 2

The browser-based model


Browser model: Pros and cons

• Pros– No software or licenses to install on the client– Easy to push out new releases– More technologies to master– App available anywhere to a user

• Cons– Must be written with performance in mind– UI is potentially less rich that fat client– Browser differences require good testing


Starting a new Web app


A suggested Web application structure

• In Web apps, the folder structure is very important

• It is also, at least mostly, up to you

• What follows is a suggested way to order your Web app folder structure

• A template, and instructions, for this structure is included in the Palooza downloads– ftp://ftp.asna.com/public/palooza2013/


Using the basic Web project template

• Download the template zip file (from the Palooza2013 downloads

• Put the zip file in this folder on your development PC:

C:\Users\{user}\Documents\Visual Studio 2012\Templates\ProjectTemplates


When the template is installed, you’ll see it as shown in the redrectangle when you start a new AVR Web site.


Basic Web app folder structure

• Public folder– Publicly available app

components

• Views folder– Content pages

• Master page(s)

• Configuration file

• Application events handler


Basic contents of Web site

• Public folder– This is were you put Web site components that

should be available to any user—authenticated or not

• Views folder– All ASPX content pages

• Web.Config – configuration file

• Global.asax – global application events


Managing application state persistence


Persisting application state

• View state

• Session state

• Application state


View state

• Think of view state as a page-level LDA—values persisted only for a given page

• Pros– Nothing is persisted on the server– Easy to use

• Cons– Limited to single page– Increases size of page


Session state

• Session-side variable persistence—available across all pages for a single session (Session-wide LDA)

• Pros– Easy to use– Data available across all pages for a session

• Cons– Uses server memory– Need to be explicitly removed when you’re done

with them– Browser must have session cookies enabled


Application state

• Persists values for all users (Application wide LDA)

• Pros– Easy to use– Good for shared variables

• Cons– Browser must have session cookies enabled


Managing DB connections and open files


The stateless nature of Web apps affects DB connections and file use• Each page must following this cycle:– Connect the DB– Open files– Do work– Close files– Disconnect the DB

• Just as we saw the Counter not persist, neither do DB connections and open files


What is connection pooling?

• Connection pooling is DataGate’s ability to “reuse” database server jobs between stateless IO requests

• Connection pooling applies mostly to stateless Web applications or Web services.

• Rarely is connection pooling helpful to Windows-based programs– It’s not likely to hurt anything, but connection pooling is

especially suited for stateless apps


Connection pooling: the IBM i

• Effective connection pooling is especially important if the IBM i is your database platform

• Without connection pooling, a new IBM i job must be created for each request. This can take 3-10 seconds—depending on IBM i load and configuration

• With connection pooling, an IBM i job is made available to a request in a matter of milliseconds


Connection pooling: SQL Server

• Although instancing a database connection isn’t quite the performance drain on SQL Server that it is on the IBM i, it’s still a drain

• It may also affect SQL Server licensing– Because you are in effect also pooling licensing (for CAL-based

licenses)

– Connection pooling keeps any one connection is play for the

minimum amount of time

• This discussion is primarily System i-centric, but everything said here about connection pooling also applies to DataGate for SQL Server


Enabling connection pooling

• Connection pooling can be enabled statically through database name attributes

• Or set dynamically through changing the database object’s PoolingTimeOut property prior to connecting that object


Enabling connection pooling statically

• Connection pooling is enabled with the DataGate Explorer’s“Edit properties” panel for a Database name


Enabling connection pooling dynamically

• Connection pooling can also be controlled by setting the database object’s PoolingTimeout value.

• Any value greater than zero sets the connection pooling timeout value (in minutes); zero disables connection pooling


What’s a good time-out value?

• That depends.

• For many shops, something in the range of 20 minutes or so works well

• However, we have customers that use much larger values if the latency between pages is extreme– Shop floor browser-based applications for

example


How does connection pooling it work?• Red zone= inactive pooled jobs

• Green zone = active jobs

• At this point, application has no jobs pooled


Blue and pink: cool and warm

• For purposes of this discussion:– Blue users get new, previously unpooled jobs.

These uses wait 3-7 seconds for their page.– Blue jobs are new, previously unpooled jobs.– Pink users get a pooled job. These users wait

just a few milliseconds for their page.– Pink jobs are previously pooled jobs.

Think of it this way, blue users/jobs are cool; pink users/jobs are warm!


A user request occurs

• DataGate first looks in the red job zone for a previously pooled job. There isn’t one. DataGate starts a new one.


The job is now pooled

• When the server is done servicing the user’s request, the job is “moved” to the pooled zone

• Pooled jobs have no open files, no activity, and consume very few IBM i resources


Same user requests a second page

• Because there is a job in the pooled zone, that job is made available in just a few milliseconds


The job is put back in the pool

• When the server is done servicing the user’s request, the job is “moved” to the pooled zone again


Two users request a page within 1 MS of each other• The first user gets the previously pooled job

• The second user has to wait for IBM i to create a new job


Now two jobs are pooled

• Two jobs are pooled

• With two jobs pooled, the two users are both guaranteed a pooled job


Three users request a page within a couple of MS of each other• Two user get a pooled job; the third user waits for a new job

• For most Web apps, jobs aren’t unique to a user, so the two pooled jobs are avaiable to the first two users—independent of who previously used the two pooled jobs


Now three jobs are pooled

• The inactive job pool is now somewhat populated

• Lots of users can come and go through these three jobs


The benefit of a populated pooled zone

• As the pooled zone gets populated, it less likely that new jobs will be needed

• After get five or six pooled, what are the chances that five or six users will each request a page within a few hundred or so milliseconds of each other?

• Of course, it could happen. And if it does, a new job is added and the pooled zone grows by one


20 or 30 to one!

• ASNA benchmarks show that you can expect at least 20 or 30 users able to do “normal” work using a single pooled job

• As the load grows, so grows the pooled zone

• But pooled jobs have a very low impact on the IBM i

35

Lots of users busy with few jobs


How does the pooled zone get cleared out• By job timeout value

– First in, first out• For example with no activity, a job drops out of the pooled

zone when its timeout value expires


How to tell if it’s working

• Performance is a very good way to tell if connection pooling is working

• However, another way to ensure it’s working is to test youre app, through several pages, knowing only one user is using it

• If, after using the app for a while you have more than one IBM i job active, something is amiss

37

Something is wrong here!There are three jobs for an application with a single user!


Something else to watch for

• It’s possible to be using connection pooling correctly and still get more than one job active

• This can happen when a Web page uses one or more secondary classes where each of which establishes its own DB connection

• This topic is out of the scope of this presentation, but if you think this is happening to you, read about the Singleton DB pattern explanation in the Palooza download materials

39


The rules of connection pooling

• Enable it either statically or dynamically

• The next point is very important!

• Each page must following this cycle:– Connect the DB– Open files– Do work– Close files– Disconnect the DB

40


Your app must disconnect for every page!

• A job gets moved back to the pooled zone when it’s disconnect

• If you don’t disconnect, you aren’t pooling jobs!

• The Page’s Unload event is a good place to put your closes and disconnect

41


Consider doing this:

• Use Close *All to close all files– This gracefully closes all open files– Doesn’t choke if none are opened

• Then disconnect

42


Don’t forget to close files!

• If you disconnect but don’t close files, you cause lots of filesto be opened!

• Close *All

• then disconnect

43


Remember this!

• If you don’t close files and disconnect the DB object before the page goes out of scope, you are not using connection pooling!

• The same advice applies to Web methods (which are a way to do Ajax with ASP.NET). Close files and disconnect the DB after every Web method call

44


Your app must disconnect for every page!• A job gets moved back to the pooled zone when it’s

disconnected

• If you don’t disconnect, it’s an orphan active job

45


Pooled connection scope

• Pooled connections are uniquely identified by all of the properties of a database name.

• Thus, if each user is signing on to your Web app with her user profile and password, you are negating the scalable benefits of connection pooling– You are however, letting users get their jobs back quickly

46


Pooled connection scope

• Some shops can’t use a single database name for all users (ie, a single user ID and password). Thanks Sarbanes Oxley or other regulations.

• Consider using three or database names to group users (perhaps by security or function)

• This way you’re at least getting some scalability by letting each group share pooled jobs

47


Limiting database platform jobs

• When you instance a class that has a DB object, and that class connects, that class gets its own job on the database platform

• This means that it’s very easy for any one program (Windows or Web) to have several jobs in play for that one program

• This… is not good!

48


Limiting database platform jobs

• Note the following discussion applies to Windows and Web AVR apps, but not to Monarch-generated apps

49


An example with two classes

• Two classes, two DBs, two connects = two jobs

50

This is especially troubling on the System i. Scalability goes out the window if you aren’t careful!


The solution: the singleton DB pattern• A parent class

passes its job to its children, the children to their children

• Results in just one job for the instance of the program

51


The bad scenario

• Here both classes get their job

• This effects Windows and Web programs

52

53

To limit the database platform one job, the parent class needs to pass its DB object around to its children (and them to their children if they have any.


There are just a few rules

• The parent, top level class, must pass its DB object on

• The parent must disconnect the DB

• Child can never disconnect– Others might want the job

• Children can connection the DB, but should check to see if it needs to be – Others might have previously connected it

54


The singleton DB pattern is well-documented

• The downloads for Palooza (associated with this session) includes a detailed description of the singleton DB pattern

• Factor it into all of your programs!

• If you don’t, you are risking scalability on your database server

55


Beware shared DB connections!

• Do not share DB connections in Web applications

• This forces all users to wait on a single thread for DB connections

• This is guaranteed to make you stay up late at night

56


Consider (carefully) if using threading can help your application performance

• Spinning off certain processes can help application performance

• One place where using threading is effective is to cause Web services to fire off a thread (to start a long-running process) and quickly return

• Here is an abbreviated example…

Spinning off the SubmitPrint process on its own thread.