Bug 1029555

We've encountered the following issues using MS Sql server 2008 R2 SP2 with a custom extension with about 2000 pages. 

1) slowness
If setting MS Sql server collation as case insensitive(which is the default), for example Latin1_General_CI_AS, the custom extension can be loaded in about 30 mins. The same extension could be loaded in 2, 4 and 10 mins if using H2, Postgres and mysql respectively. 
If setting MS Sql server collation as case sensitive,for example Latin1_General_CS_AS, which is required by eXo JCR in http://docs.jboss.org/exojcr/1.15.1-GA/developer/en-US/html_single/ in section 1.18.1.4. MS SQL configuration, the JPP 6.0/6.1 can never be started up. It hangs there forever.

2) incompletely load data
If setting MS Sql server collation as case insensitive(which is the default), for example Latin1_General_CI_AS, the custom extension can be loaded in about 30 mins. However, the data is not completely loaded. 
The query "select count(*) from dbo.JCR_IPSYSTEM;" returns about 138413(this number varies each time) records in MSSQL server, and same query on postgress and mysql returns 201334 records.
As a result, after the JPP is fully started up when accessing the portal http://host:port/portal, it gives 404 error.

eXo has tested MS Sql server 2008 RTM version(no SP). They said if setting the collation as case sensitive they can load the extension without issue. 
********************************************************************************
We redo the test in our local environment:
Environment description:
jboss-jpp-6.0
JCR-1.15.1-CP01-redhat-1
MSSQL RTM Enterprise Edition (64-bit) 10.0.1600.22	
sqljdbc-3.0.1301.101.jar
JPP instance and MSSQL are located on different boxes.
We use a case sensitive collation Latin1_General_CS_AS for JCR schema
Startup time:
First startup 1140134ms(around 20 min)
Second startup 40300ms(around 0.6 min)
I can access to access http://localhost:8080/portal/classic
Portal is showing up.
select count from dbo.JCR_IPSYSTEM;" returned 200148
********************************************************************************

We have reproduced the issue using MS Sql server 2008 R2 SP2 instance in QE lab. We need to run another test on a MS Sql server 2008 RTM instance to confirm that there's no such issue in that sql server version.