Profile cover photo
Profile photo
Darren Gavin
34 followers -
Software Developer | Amatuer Vulcanologist | Metal Head
Software Developer | Amatuer Vulcanologist | Metal Head

34 followers
About
Darren's posts

SQL Injection Scanning

Just a heads up, at work the last few days we've been seeing some attempts at SQL Injection on web sites.

Our web applications have been hardened against this, but after 3 years without an attempt in the logs, seems these are starting up again.

LINQ2SQL intresting facts.

Something I discovered recently about using LINQ to go after SQL databases to take note of.

Here was the Senerio

Ran a query on a large table (150,000 rows with 5 columns) and stored that in application cache.

Application then when needed, did a Linq on primary key on that cached LINQ collection.

Result: Linq Re-ran the origianal query, instead of going after the data already in the collection. Additionally was unable to close (close not discard) the DB Connection that was asscociated with that collection.

So I tried a few other things.

1. Ran same linq, and the iterated (foreach) every row in that collection.
2. Iterated the collection a second time and verified it re-ran the origianl SQL query and had to return all that data a second time.

Conclusions:
Linq2SQL is a form of late bound query, and each access of a existing collection (foreeach or additional LINQ statements) in code will cause a new query to run, all the data to trasfer again, making it impractical to use for when you want to cache into memory table that arn't update frequently for higher performance.

Additionally LINQ2SQL does not close the DBConnection, leading to the built in .net connection pooling to not fuction as it's supposed too. Each user or web session gets a different Connection object and they always stay open until the end of a web page. If you put the collection into application cache, that connection stays open until the server is reset.

For high performance applications that need to precache some table, LINQ is not a good solution, better off to use ado.net (system.data.SQLClient) and then cache the raw DataTable object. (Unfortunately LINQ doesn't use the DataTable object behind the scenes so you can't get at that with system reflection).

Performance Metrics on the above table (150K rows) with LINQ followed by 100 primary key sub queries on that collection, then DataTable with the same (after manualy indicating the primary key field on the in core datatable), and then loading both to a Dictionary generic collection class and doing the same 100 fetches.

Linq - 9.87 seconds

DataTable - 0.0987 seconds

Linq Loading to Dict collection .0104 seconds
Reading Dict 0.0012 seconds

DataTable loading to Dict collection .0367 seconds
Reading Dict 0.0012 seconds

After running the metirics, for truely highest performance needs when those arise, reloading a DataTable or a Linq collection's data into a Dictionary would be the best method of caching data. (unless you need the table updated event callbacks to reload from an updated table, in which case a DataTable would be the next best option)

However in the end remember that LINQ2SQL collections have connection pooling issues, and will rerun origianl queries instead of working on the data already in memory on each access of those collections. So while LINQ may be good for smaller applications that don't get much use, for larger or highly used applications, staying with ado.net classes is the better option.

I also found that when doing complex joined queries, (4 tables or more inner or left joined) that ado.net also significantly outperforms LINQ2SQL.

Please note, i'm not saying LINQ itself is bad, just saying the LINQ2SQL interface has some issues that are not very good for larger or high use applications.

Bad Scripters...

Being a developer I tend to run browsers in a mode that reports errors. The latest annoying broken javascript is from plug.onswipe.com, thats seem to be infecting a ton of news services.

Hitting this a lot so adding them to my hosts file to block thier sites.

I'll be thankfull for a day if browsers are brought to a standard that reduces or emilinates the need for extensive java scripting.

It's far past the time for browsers, and time for an application presentation standard that encompases some HTML, but focuses more on C/S and Cloud interactions with out the need for javascripting, JQuery and bloated AJAX libraries, etc...

I don't mind javascripting when its tested properly, however from the error reports I see on most web sites, most don't bother testing thier javascripts well.

Flodding gone down, but not out of the woods yet, storm ariving next week.

The Willamate River through Salem area currently has a Flow rate of 150,000 cfs. For perpective, Niagara falls has a flow of 200,000 cfs.

Post has attachment
PhotoPhotoPhotoPhoto
Skyrim Collection (4 photos)
4 Photos - View album

Flooding, Flooding and more Flooding.

As if the hour drive to work this morning (normaly a 10-15 minute drive) was bad enough due to floods.

As if a gale force storm warning issued on the coast latert today wasn't even worse, which should blow in tonight some time.

How about a storm drain close to the top of a hill, overflowing onto the street right infront of my house, one of the higest elevation points in salem.

This week is tuning out to be one keck of a year.

Identifying Overpayment Scams

This is actualy easy, if you are selling something and recieve an overpayment for the goods. It's a Scam. Period.

But how do you really know?

Take a magnifying glass and examine the Line that signatures go on, if the solid looking line really is solid that the check is a fake.

All, and I mean all checks, including Warrents issued by governments, have a solid /looking/ line that is actually Micro-printing.

Under a magnifying glass you should see something like tiny words, typically "Authorized Signature Only" repeated many times. In the case of Warrents its some other wording that varys.

So if the signature line is actualy a solid black line, it's a fake check. Simple as that.

Java Wars Fallout Already?

Maybe...

One of the minor things I do on my job is keep our subversion server updated, and functioning. Today one of my co-workers installed the 1.7 upgrade for the Tourtise client, at which point they were unable to access anything on the subversion server properly.

So I went out to the Collabanet web site and investigated Subversion Edge 1.7 and saw this blub at the top of thier list of updates in 1.7.

Major Infrastructure Changes.

Oh...joy...

I didn't have time to download the update yet and take a peek, but I suspect that they might have moved from the Oracle/Sun VM to the IBM/Apachee J9 VM (Apogee). Atleast thats my best guess.

Either way its looking like the 1.7 Subversion Clients (atleast Tourtise) will not be compatible with 1.6 Subversion Servers. Don't be in a rush to update yet.

Working on my first Circle, that of Computer Programmers and IT professionals, doing this through searches so if any already have shared circles for this I would definately appreciate pulling from them.

Post has shared content
Wait while more posts are being loaded