bodington-developers — Mailing list for Bodington developers

Re: [Bodington-developers] access log

[Matthew B. <mat...@ou...>]

Alistair Young wrote:
> Where does the access log thingy get it's data from? Is it a db  
> table? Manage -> Access log

Events table. Its a summary of the navigation events for the current 
resource.

-- 
  -- Matthew Buckett, VLE Developer
  -- Learning Technologies Group, Oxford University Computing Services
  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/

Re: [Bodington-developers] Locking Issues (Java, Explicit DB, Optimistic DB)

[Matthew B. <mat...@ou...>]

Jon Maber wrote:
> Matthew Buckett wrote:
>> User 1: get current quota 8.5MB of 10MB
>> User 2: get current quota 8.5MB of 10MB
>> User 2: set quota to 9.5MB and upload 1MB file.
>> User 1: set quota to 10.5MB and upload 1MB file.
>>
>> Now user 1 has exceeded the quota but still has the file uploaded which 
>> shouldn't be allowed (or should it?)
>>
>> The other option is to check after changing the quota with another 
>> select that the quota is set to the expected value (although this really 
>> is just an expansion of the collection of fields update)
> I'll let you and Ian discuss the general case (because id have to study 
> a book on the subject to catch up with you).
> 
> Did you say if your code is directly calls the SQL or wraps records in 
> the quotas table in a Bodington PersistentObject subclass?

At the moment I don't have a quota table but use two metadata entries as 
most of the time we don't need to know the quota so performance isn't 
crucial. This could change in the future.

> If the latter then database reading and writing will operate through a 
> single instance of that class so you could add a method like this;
> 
> public synchronized boolean attemptUpload( long size )
> {
> // this class knows the value of current uploaded bytes
> // return false if already over limit.
> // add to uploaded bytes record.
> // call standard save record routine
> // return true
> }
> 
> The important thing is that this routine does the 'over limit' 
> calculation and the save record part in the same synchronized block.

Even if I don't have a Quota class I could do the synchronization on the 
resource object to which the quota is attached. This only works in a 
single JVM although there are some projects attempting to weave extra 
bits in to allow locking primatives to work across JVMs.

http://www.terracottatech.com/terracotta_Spring.shtml

-- 
  -- Matthew Buckett, VLE Developer
  -- Learning Technologies Group, Oxford University Computing Services
  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/

Re: [Bodington-developers] access log

[Matthew B. <mat...@ou...>]

2nd attempt...

Alistair Young wrote:
> Where does the access log thingy get it's data from? Is it a db  
> table? Manage -> Access log

Events table. Its a summary of the navigation events for the current
resource.

-- 
  -- Matthew Buckett, VLE Developer
  -- Learning Technologies Group, Oxford University Computing Services
  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/

Re: [Bodington-developers] access log

[Sean M. <se...@sm...>]

we need to know in order that we might start to get at the data for  
reporting.

s

On 14 Jun 2006, at 12:21, Alistair Young wrote:

> Where does the access log thingy get it's data from? Is it a db
> table? Manage -> Access log
>
> Alistair
>
>
>
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>

Re: [Bodington-developers] Demo users and resources

[Matthew B. <mat...@ou...>]

Jon Maber wrote:
> There used to be the option to create demo users and resources in the 
> Bodington setup servlet. Has that been hidden away somewhere? I need to 
> create a load of users for testing and was hoping for a shortcut.

The code is still there I think, I'm not sure if the interface gives you 
the option.

-- 
  -- Matthew Buckett, VLE Developer
  -- Learning Technologies Group, Oxford University Computing Services
  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/

Re: [Bodington-developers] Locking Issues (Java, Explicit DB, Optimistic DB)

[Matthew B. <mat...@ou...>]

Peter Crowther wrote:
>> From: Matthew Buckett
>> If we updated to TRANSACTION_REPEATABLE_READ 
>> then we don't have to 
>> worry about a read row being modified under our feet.
> 
> Sorry, doesn't work - you have to go to SERIALIZABLE on MSSQL at least.
> Otherwise:
> 
> - A reads (acquires read lock);
> - B reads (acquires read lock);
> - A adds;
> - B adds;
> - A updates (tries to upgrade to write lock, waits on B's read lock);
> - B updates (tries up upgrade to write lock, system detects deadlock and
> rolls back one transaction).
> 
> ... Causes problems at best, deadlock at worst, I think.

Yep your right. As a side note PostgreSQL implements 
TRANSACTION_REPEATABLE_READ as SERIALIZABLE.

-- 
  -- Matthew Buckett, VLE Developer
  -- Learning Technologies Group, Oxford University Computing Services
  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/

Re: [Bodington-developers] Locking Issues (Java, Explicit DB, Optimistic DB)

[Peter C. <Pet...@me...>]

> From: Matthew Buckett
> If we updated to TRANSACTION_REPEATABLE_READ=20
> then we don't have to=20
> worry about a read row being modified under our feet.

Sorry, doesn't work - you have to go to SERIALIZABLE on MSSQL at least.
Otherwise:

- A reads (acquires read lock);
- B reads (acquires read lock);
- A adds;
- B adds;
- A updates (tries to upgrade to write lock, waits on B's read lock);
- B updates (tries up upgrade to write lock, system detects deadlock and
rolls back one transaction).

... Causes problems at best, deadlock at worst, I think.

		- Peter

Re: [Bodington-developers] Locking Issues (Java, Explicit DB, Optimistic DB)

[Ian B. <ia...@ca...>]

More comments below (quick this time promise)

Matthew Buckett wrote:
> Ian Boston wrote:
>> Quick comments below...
>>
>>> I can see that you may end up with BIG update statements if the table 
>>> has a large number of columns, or some columns with big fields.
>> thats probably ok, if you dont mind maintaining the SQL. The additional 
>> performance hit of 1 long/timestamp to 4 or 5 varchars probably isnt 
>> significant. (but don't do it with a BLOB/CLOB, not that you can anyway :) )
>>
>>
>>>> It doesn't rely on any one transaction isolation mechanism (other than 
>>>> no transaction), provided that there is a transaction in place.
>>>>
>>>> If you have a well know point through which all db object access flows, 
>>>> you could put it in as an option on all db objects.
>>>>
>>>>
>>>> (I use this in Sakai RWiki, and Sakai Search to do optimistic locking 
>>>> and to ask the user which version they want to commit to the database, 
>>>> old or new)
>>> Even if you don't involve the web layer I have the problem with quota in 
>>> that I need to do:
>>>
>>> SELECT currentQuota, limitQuota FROM quotas WHERE resource = 1;
>>> check in Java if uploading the new file will push the current quota over 
>>> the limit, if not update the quota and upload the file:
>>> UPDATE quotas SET currentQuota = currentQuota+fileSize WHERE resource = 1;
>>>
>>> The problem is that two people may be uploading at the same time so you 
>>> might get:
>>>
>>> User 1: get current quota 8.5MB of 10MB
>>> User 2: get current quota 8.5MB of 10MB
>>> User 2: set quota to 9.5MB and upload 1MB file.
>>> User 1: set quota to 10.5MB and upload 1MB file.
>>>
>>> Now user 1 has exceeded the quota but still has the file uploaded which 
>>> shouldn't be allowed (or should it?)
> 
> As quotas are generally overallocated do we care about people exceeding 
> them a little and then prevent the next upload?
> 
>>> The other option is to check after changing the quota with another 
>>> select that the quota is set to the expected value (although this really 
>>> is just an expansion of the collection of fields update).
>>
>> If the quota had a version stamp, then you could check that for changes 
>> in the update statement
>>
>> This is Oracle speak, the updates might have to be in 2 steps in MySQL 4
> 
> Yep:
> 
>> eg
>>  > User 1: get current quota 8.5MB of 10MB (ver= 12345)
>> SELECT
>> 	currentQuota,
>> 	limitQuota,
>> 	version
>>     FROM quotas
>>    WHERE resource = 1;
>> request version now 12345
> 
> SELECT currentQuota, limitQuota FROM quotas WHERE resource = 1 FOR
> UPDATE;
> 
> which succeeds.
> 
>>  > User 2: get current quota 8.5MB of 10MB
>> SELECT
>> 	currentQuota,
>> 	limitQuota,
>> 	version
>>     FROM quotas
>>    WHERE resource = 1;
>> request version now 12345
> 
> 
> SELECT currentQuota, limitQuota FROM quotas WHERE resource = 1 FOR
> UPDATE;
> 
> which blocks until the first transaction completes.
> 
> [...snipped..]
> 
>> user is informed
> 
> I know there are several ways of solving the problem and am just 
> wondering which we should head down. Which comes back to the question of 
> caring about multiple JVMs.

I don't know the code, but it the request cycles are detached (ie all 
the steps are in separate request cycles) and the transactions are 
completed the optimistic locking works.

If there are just 2 cycles, one for user1 and one for use2 then the 
transaction manager will solve the problem......

*but* be wary of long transactions..... you *will* get deadlocks under 
load if you use long transactions, Oracle you can configure to avoid, by 
MySQL+InnoDB there is nothing you can do, there is a bit in the manual 
about it. Select for Update locks neighboring records in the index in 
MySQL, in Oracle the lock is maintained in a part of the DB block 
(inittrans)

Transaction locking only works if the transactions are intertwined, the 
the for update controls things.

Just in case you were tempted (which Im almost certain you are not) dont 
go for pessimistic locking in the DB unless you want to become great 
friends with you DBA's (not), in Sakai 1.0 there were db pessimistic 
locks.... what fun!

Ian

On the other hand
you might have great DBA's who you want to get 'friendly' with :)

> 
> I haven't started doing any code for this yet.
> 

[Bodington-developers] access log

[Alistair Y. <ali...@sm...>]

Where does the access log thingy get it's data from? Is it a db  
table? Manage -> Access log

Alistair

Re: [Bodington-developers] Locking Issues (Java, Explicit DB, Optimistic DB)

[Matthew B. <mat...@ou...>]

Ian Boston wrote:
> Quick comments below...
> 
>> I can see that you may end up with BIG update statements if the table 
>> has a large number of columns, or some columns with big fields.
> 
> thats probably ok, if you dont mind maintaining the SQL. The additional 
> performance hit of 1 long/timestamp to 4 or 5 varchars probably isnt 
> significant. (but don't do it with a BLOB/CLOB, not that you can anyway :) )
> 
> 
>>> It doesn't rely on any one transaction isolation mechanism (other than 
>>> no transaction), provided that there is a transaction in place.
>>>
>>> If you have a well know point through which all db object access flows, 
>>> you could put it in as an option on all db objects.
>>>
>>>
>>> (I use this in Sakai RWiki, and Sakai Search to do optimistic locking 
>>> and to ask the user which version they want to commit to the database, 
>>> old or new)
>> Even if you don't involve the web layer I have the problem with quota in 
>> that I need to do:
>>
>> SELECT currentQuota, limitQuota FROM quotas WHERE resource = 1;
>> check in Java if uploading the new file will push the current quota over 
>> the limit, if not update the quota and upload the file:
>> UPDATE quotas SET currentQuota = currentQuota+fileSize WHERE resource = 1;
>>
>> The problem is that two people may be uploading at the same time so you 
>> might get:
>>
>> User 1: get current quota 8.5MB of 10MB
>> User 2: get current quota 8.5MB of 10MB
>> User 2: set quota to 9.5MB and upload 1MB file.
>> User 1: set quota to 10.5MB and upload 1MB file.
>>
>> Now user 1 has exceeded the quota but still has the file uploaded which 
>> shouldn't be allowed (or should it?)

As quotas are generally overallocated do we care about people exceeding 
them a little and then prevent the next upload?

>> The other option is to check after changing the quota with another 
>> select that the quota is set to the expected value (although this really 
>> is just an expansion of the collection of fields update).
> 
> 
> If the quota had a version stamp, then you could check that for changes 
> in the update statement
> 
> This is Oracle speak, the updates might have to be in 2 steps in MySQL 4

Yep:

> eg
>  > User 1: get current quota 8.5MB of 10MB (ver= 12345)
> SELECT
> 	currentQuota,
> 	limitQuota,
> 	version
>     FROM quotas
>    WHERE resource = 1;
> request version now 12345

SELECT currentQuota, limitQuota FROM quotas WHERE resource = 1 FOR
UPDATE;

which succeeds.

>  > User 2: get current quota 8.5MB of 10MB
> SELECT
> 	currentQuota,
> 	limitQuota,
> 	version
>     FROM quotas
>    WHERE resource = 1;
> request version now 12345


SELECT currentQuota, limitQuota FROM quotas WHERE resource = 1 FOR
UPDATE;

which blocks until the first transaction completes.

[...snipped..]

> user is informed

I know there are several ways of solving the problem and am just 
wondering which we should head down. Which comes back to the question of 
caring about multiple JVMs.

I haven't started doing any code for this yet.

-- 
  -- Matthew Buckett, VLE Developer
  -- Learning Technologies Group, Oxford University Computing Services
  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/

[Bodington-developers] Demo users and resources

[Jon M. <jo...@te...>]

There used to be the option to create demo users and resources in the 
Bodington setup servlet. Has that been hidden away somewhere? I need to 
create a load of users for testing and was hoping for a shortcut.

Jon

Re: [Bodington-developers] Locking Issues (Java, Explicit DB, Optimistic DB)

[Jon M. <jo...@te...>]

Matthew Buckett wrote:
> User 1: get current quota 8.5MB of 10MB
> User 2: get current quota 8.5MB of 10MB
> User 2: set quota to 9.5MB and upload 1MB file.
> User 1: set quota to 10.5MB and upload 1MB file.
>
> Now user 1 has exceeded the quota but still has the file uploaded which 
> shouldn't be allowed (or should it?)
>
> The other option is to check after changing the quota with another 
> select that the quota is set to the expected value (although this really 
> is just an expansion of the collection of fields update)
I'll let you and Ian discuss the general case (because id have to study 
a book on the subject to catch up with you).

Did you say if your code is directly calls the SQL or wraps records in 
the quotas table in a Bodington PersistentObject subclass?

If the latter then database reading and writing will operate through a 
single instance of that class so you could add a method like this;

public synchronized boolean attemptUpload( long size )
{
// this class knows the value of current uploaded bytes
// return false if already over limit.
// add to uploaded bytes record.
// call standard save record routine
// return true
}

The important thing is that this routine does the 'over limit' 
calculation and the save record part in the same synchronized block.

Jon

Re: [Bodington-developers] Locking Issues (Java, Explicit DB, Optimistic DB)

[Ian B. <ia...@ca...>]

Quick comments below...

Matthew Buckett wrote:
> Ian Boston wrote:
> 
> Thanks Ian...
> 
>> Transaction manager would work,
>> if using Spring you could use Spring JDBC, which just places the 
>> transaction manager in by defining the methods to manage.
>> Alternatively (if feeling brave) you could do an AOP point cut (is that 
>> the right term ?) to intercept the calls (in essence what Spring does).
>>
>> However the transaction manager solution will only work for the Same 
>> JVM, and will not address the syncronisation issue between requests.
> 
> Do we care about this? Do we ever plan to allow bodington to run across 
> several JVMs?
> 
>> eg
>>
>> User1 goes to web page, reads doc, decides to update.
>> User2 reads doc (faster:)), updates
>> User2 begins upload and overwrites user1's docs.
>>
>> The solution is to use Optimistic Locking implemented as a Timestamp or 
>> long/bigint in the record. (ed System.currentTimeMillis() ), this 
>> travels around with the web page, so when User1 tries to overwrite, they 
>> are told that the *point* at which they were overwriting from is now 
>> invalid.
> 
> This is the general problem which bodington at the moment doesn't solve :-(
> 
>> This is a standard Hibernate technique, there is an explicit version 
>> field in hbm files to do optimistic locking, but it can just as well be 
>> done with JDBC. Its a bit more robust and generic than the collection of 
>> fields approach, and works on all db objects.
> 
> Yep. For Bodington this might be a reasonably easy fix as all our DB 
> objects are linked to the objects table so we could add the locking 
> field there.
> 
> As long as you have TRANSACTION_READ_COMMITTED why is the collection of 
> fields approach problematic?


yes that you have to remember which ones and carry them all around 
though the request cycle, it really easy if you always take a version 
field with all objects.




> 
> I can see that you may end up with BIG update statements if the table 
> has a large number of columns, or some columns with big fields.

thats probably ok, if you dont mind maintaining the SQL. The additional 
performance hit of 1 long/timestamp to 4 or 5 varchars probably isnt 
significant. (but don't do it with a BLOB/CLOB, not that you can anyway :) )


> 
>> It doesn't rely on any one transaction isolation mechanism (other than 
>> no transaction), provided that there is a transaction in place.
>>
>> If you have a well know point through which all db object access flows, 
>> you could put it in as an option on all db objects.
>>
>>
>> (I use this in Sakai RWiki, and Sakai Search to do optimistic locking 
>> and to ask the user which version they want to commit to the database, 
>> old or new)
> 
> Even if you don't involve the web layer I have the problem with quota in 
> that I need to do:
> 
> SELECT currentQuota, limitQuota FROM quotas WHERE resource = 1;
> check in Java if uploading the new file will push the current quota over 
> the limit, if not update the quota and upload the file:
> UPDATE quotas SET currentQuota = currentQuota+fileSize WHERE resource = 1;
> 
> The problem is that two people may be uploading at the same time so you 
> might get:
> 
> User 1: get current quota 8.5MB of 10MB
> User 2: get current quota 8.5MB of 10MB
> User 2: set quota to 9.5MB and upload 1MB file.
> User 1: set quota to 10.5MB and upload 1MB file.
> 
> Now user 1 has exceeded the quota but still has the file uploaded which 
> shouldn't be allowed (or should it?)
> 
> The other option is to check after changing the quota with another 
> select that the quota is set to the expected value (although this really 
> is just an expansion of the collection of fields update).


If the quota had a version stamp, then you could check that for changes 
in the update statement

This is Oracle speak, the updates might have to be in 2 steps in MySQL 4

eg
 > User 1: get current quota 8.5MB of 10MB (ver= 12345)
SELECT
	currentQuota,
	limitQuota,
	version
    FROM quotas
   WHERE resource = 1;
request version now 12345

 > User 2: get current quota 8.5MB of 10MB
SELECT
	currentQuota,
	limitQuota,
	version
    FROM quotas
   WHERE resource = 1;
request version now 12345

User 2: set quota to 9.5MB
UPDATE quotas
	SET currentQuota = currentQuota+fileSize,
	version = 123444
   WHERE resource = 1
     and version = 12345;

request version now = 123444

and upload 1MB file.
UPDATE
	resources r,
	qota q
     SET r.body = filedata,
	q.version = 12555
   WHERE r.resource = q.resource
     and q.version = 12444
     and q.resource = 1

request version now = 123555

 > User 1: set quota to 10.5MB and upload 1MB file.


> 
UPDATE quotas
	SET currentQuota = currentQuota+fileSize,
	version = 123666
   WHERE resource = 1
     and version = 12345;

BOOM! no update
request version still 12345

and upload 1MB file.
UPDATE
	resources r,
	qota q
     SET r.body = filedata,
	q.version = 12777
   WHERE r.resource = q.resource
     and q.version = 12345
     and q.resource = 1

BOOM! no update,
request version still 12345

user is informed

Re: [Bodington-developers] Locking Issues (Java, Explicit DB, Optimistic DB)

[Matthew B. <mat...@ou...>]

Ian Boston wrote:

Thanks Ian...

> Transaction manager would work,
> if using Spring you could use Spring JDBC, which just places the 
> transaction manager in by defining the methods to manage.
> Alternatively (if feeling brave) you could do an AOP point cut (is that 
> the right term ?) to intercept the calls (in essence what Spring does).
> 
> However the transaction manager solution will only work for the Same 
> JVM, and will not address the syncronisation issue between requests.

Do we care about this? Do we ever plan to allow bodington to run across 
several JVMs?

> eg
> 
> User1 goes to web page, reads doc, decides to update.
> User2 reads doc (faster:)), updates
> User2 begins upload and overwrites user1's docs.
> 
> The solution is to use Optimistic Locking implemented as a Timestamp or 
> long/bigint in the record. (ed System.currentTimeMillis() ), this 
> travels around with the web page, so when User1 tries to overwrite, they 
> are told that the *point* at which they were overwriting from is now 
> invalid.

This is the general problem which bodington at the moment doesn't solve :-(

> This is a standard Hibernate technique, there is an explicit version 
> field in hbm files to do optimistic locking, but it can just as well be 
> done with JDBC. Its a bit more robust and generic than the collection of 
> fields approach, and works on all db objects.

Yep. For Bodington this might be a reasonably easy fix as all our DB 
objects are linked to the objects table so we could add the locking 
field there.

As long as you have TRANSACTION_READ_COMMITTED why is the collection of 
fields approach problematic?

I can see that you may end up with BIG update statements if the table 
has a large number of columns, or some columns with big fields.

> It doesn't rely on any one transaction isolation mechanism (other than 
> no transaction), provided that there is a transaction in place.
> 
> If you have a well know point through which all db object access flows, 
> you could put it in as an option on all db objects.
> 
> 
> (I use this in Sakai RWiki, and Sakai Search to do optimistic locking 
> and to ask the user which version they want to commit to the database, 
> old or new)

Even if you don't involve the web layer I have the problem with quota in 
that I need to do:

SELECT currentQuota, limitQuota FROM quotas WHERE resource = 1;
check in Java if uploading the new file will push the current quota over 
the limit, if not update the quota and upload the file:
UPDATE quotas SET currentQuota = currentQuota+fileSize WHERE resource = 1;

The problem is that two people may be uploading at the same time so you 
might get:

User 1: get current quota 8.5MB of 10MB
User 2: get current quota 8.5MB of 10MB
User 2: set quota to 9.5MB and upload 1MB file.
User 1: set quota to 10.5MB and upload 1MB file.

Now user 1 has exceeded the quota but still has the file uploaded which 
shouldn't be allowed (or should it?)

The other option is to check after changing the quota with another 
select that the quota is set to the expected value (although this really 
is just an expansion of the collection of fields update).

-- 
  -- Matthew Buckett, VLE Developer
  -- Learning Technologies Group, Oxford University Computing Services
  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/

Re: [Bodington-developers] Locking Issues (Java, Explicit DB, Optimistic DB)

[Ian B. <ia...@ca...>]

Transaction manager would work,
if using Spring you could use Spring JDBC, which just places the 
transaction manager in by defining the methods to manage.
Alternatively (if feeling brave) you could do an AOP point cut (is that 
the right term ?) to intercept the calls (in essence what Spring does).

However the transaction manager solution will only work for the Same 
JVM, and will not address the syncronisation issue between requests.
eg

User1 goes to web page, reads doc, decides to update.
User2 reads doc (faster:)), updates
User2 begins upload and overwrites user1's docs.

The solution is to use Optimistic Locking implemented as a Timestamp or 
long/bigint in the record. (ed System.currentTimeMillis() ), this 
travels around with the web page, so when User1 tries to overwrite, they 
are told that the *point* at which they were overwriting from is now 
invalid.

This is a standard Hibernate technique, there is an explicit version 
field in hbm files to do optimistic locking, but it can just as well be 
done with JDBC. Its a bit more robust and generic than the collection of 
fields approach, and works on all db objects.

It doesn't rely on any one transaction isolation mechanism (other than 
no transaction), provided that there is a transaction in place.

If you have a well know point through which all db object access flows, 
you could put it in as an option on all db objects.


(I use this in Sakai RWiki, and Sakai Search to do optimistic locking 
and to ask the user which version they want to commit to the database, 
old or new)

HTH
Ian

Jon Maber wrote:
> Is this another solution?
> *put a transaction manager in front of the database.
> Jon
> 
> Matthew Buckett wrote:
>> For my work on quotas I need to get the current quota, see if there is 
>> enough available to upload the new file, if so upload the file and if it 
>> succeeds increase the quota by the size of the file.
>>
>> This is easy unless two people are uploading the file in the same place 
>> at the same time.
>>
>> Solutions:
>>
>> Java Synchronisation - Portable across all platforms. Causes problems if 
>> we ever wanted to cluster Bodington across servlets engines. Initally 
>> would cause coarse locking although we could improve this.
>>
>> Explicit DB Locking - By using updatable ResultsSets rows in the 
>> database can be locked for an update so that they cannot be read by 
>> anyone else. This is an optional part of the JDBC spec but it looks like 
>> the DB platforms we use support it (MSSQL, PgSQL, MySQL).
>>
>> Optimistic DB Updates - As we seem to have the database in 
>> TRANSACTION_READ_COMMITTED then we can do queries specifying the old 
>> object values such as
>>
>> UPDATE person SET surname = "Smith" WHERE id = 3 and forenames = "Dave" 
>> and surname = "Jones";
>>
>> This way if someone else has modified the row underneath us the update 
>> fails and the application can decide what to do (try again, fail). This 
>> should work on all DBs but requires more work on the side of the 
>> application.
>>
>> Change Transaction Level - At the moment we have a isolation level of 
>> TRANSACTION_READ_COMMITTED (on PgSQL at least as we don't explicitly set 
>> it). If we updated to 	TRANSACTION_REPEATABLE_READ then we don't have to 
>> worry about a read row being modified under our feet. The problem is 
>> that not all DBs support this and we end up have lots of DB rows locked 
>> that don't need to be and as a result the DB has to work much harder. I 
>> think this is a non starter.
>>
>> Comments?
>>
>>   
> 
> 
> 
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers

Re: [Bodington-developers] Locking Issues (Java, Explicit DB, Optimistic DB)

[Matthew B. <mat...@ou...>]

Jon Maber wrote:
> Is this another solution?
> *put a transaction manager in front of the database.

By this do you mean move to using JTA? If so what do we gain from this 
over JDBC trasactions apart from abstracting transactions away from the 
implementation (which is a good thing)?

Or are you suggesting that we manage transactions on our Java objects, 
in effect move to an EJB container?

-- 
  -- Matthew Buckett, VLE Developer
  -- Learning Technologies Group, Oxford University Computing Services
  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/

Re: [Bodington-developers] Locking Issues (Java, Explicit DB, Optimistic DB)

[Jon M. <jo...@te...>]

Is this another solution?
*put a transaction manager in front of the database.
Jon

Matthew Buckett wrote:
> For my work on quotas I need to get the current quota, see if there is 
> enough available to upload the new file, if so upload the file and if it 
> succeeds increase the quota by the size of the file.
>
> This is easy unless two people are uploading the file in the same place 
> at the same time.
>
> Solutions:
>
> Java Synchronisation - Portable across all platforms. Causes problems if 
> we ever wanted to cluster Bodington across servlets engines. Initally 
> would cause coarse locking although we could improve this.
>
> Explicit DB Locking - By using updatable ResultsSets rows in the 
> database can be locked for an update so that they cannot be read by 
> anyone else. This is an optional part of the JDBC spec but it looks like 
> the DB platforms we use support it (MSSQL, PgSQL, MySQL).
>
> Optimistic DB Updates - As we seem to have the database in 
> TRANSACTION_READ_COMMITTED then we can do queries specifying the old 
> object values such as
>
> UPDATE person SET surname = "Smith" WHERE id = 3 and forenames = "Dave" 
> and surname = "Jones";
>
> This way if someone else has modified the row underneath us the update 
> fails and the application can decide what to do (try again, fail). This 
> should work on all DBs but requires more work on the side of the 
> application.
>
> Change Transaction Level - At the moment we have a isolation level of 
> TRANSACTION_READ_COMMITTED (on PgSQL at least as we don't explicitly set 
> it). If we updated to 	TRANSACTION_REPEATABLE_READ then we don't have to 
> worry about a read row being modified under our feet. The problem is 
> that not all DBs support this and we end up have lots of DB rows locked 
> that don't need to be and as a result the DB has to work much harder. I 
> think this is a non starter.
>
> Comments?
>
>   

[Bodington-developers] Locking Issues (Java, Explicit DB, Optimistic DB)

[Matthew B. <mat...@ou...>]

For my work on quotas I need to get the current quota, see if there is 
enough available to upload the new file, if so upload the file and if it 
succeeds increase the quota by the size of the file.

This is easy unless two people are uploading the file in the same place 
at the same time.

Solutions:

Java Synchronisation - Portable across all platforms. Causes problems if 
we ever wanted to cluster Bodington across servlets engines. Initally 
would cause coarse locking although we could improve this.

Explicit DB Locking - By using updatable ResultsSets rows in the 
database can be locked for an update so that they cannot be read by 
anyone else. This is an optional part of the JDBC spec but it looks like 
the DB platforms we use support it (MSSQL, PgSQL, MySQL).

Optimistic DB Updates - As we seem to have the database in 
TRANSACTION_READ_COMMITTED then we can do queries specifying the old 
object values such as

UPDATE person SET surname = "Smith" WHERE id = 3 and forenames = "Dave" 
and surname = "Jones";

This way if someone else has modified the row underneath us the update 
fails and the application can decide what to do (try again, fail). This 
should work on all DBs but requires more work on the side of the 
application.

Change Transaction Level - At the moment we have a isolation level of 
TRANSACTION_READ_COMMITTED (on PgSQL at least as we don't explicitly set 
it). If we updated to 	TRANSACTION_REPEATABLE_READ then we don't have to 
worry about a read row being modified under our feet. The problem is 
that not all DBs support this and we end up have lots of DB rows locked 
that don't need to be and as a result the DB has to work much harder. I 
think this is a non starter.

Comments?

-- 
  -- Matthew Buckett, VLE Developer
  -- Learning Technologies Group, Oxford University Computing Services
  -- Tel: +44 (0)1865 283660 http://www.oucs.ox.ac.uk/ltg/

Re: [Bodington-developers] News Feeds

[Colin T. <col...@ou...>]

Jon Maber wrote:
>> http://ramble.oucs.ox.ac.uk/blog/RAMBLE/atom.xml
>>   
> ??????
> Error in connecting to news feed server, or accessing 
> newsfeed.ramble.oucs.ox.ac.uk
> is it behind a firewall?

That's odd. I've checked it from home, and it is accessible.

Re: [Bodington-developers] 2.8 list on wiki

[Andrew B. <a.g...@le...>]

The only table whose name needed changing was 'fields'. As this is a
reserved word in MySQL, the installer changes it to 'bod_fields'. =
Whenever
the table is accessed, the code does a check to see if it is using MySQL =
and
uses the correct table name. (How long before 'classes' and 'objects' =
are
reserved words?)

MySQL 4 and 5 work fine for me, but I'd really like someone else to try =
it
before we release 2.8.  The HOWTO is in the /docs directory on the CVS.

Aggie

-----Original Message-----
From: bod...@li...
[mailto:bod...@li...] On Behalf Of
Sean Mehan
Sent: 13 June 2006 16:32
To: Bod...@li...
Subject: [Bodington-developers] 2.8 list on wiki

Thanks to all who have put their efforts into cleaning up the 2.8 list.

There are a couple of things that Matthew Bucket is best empowered to =20
look at (search on MB, and also HOW TO CHOOSE!-)

Messaging Room Moderation????

PC has an entry there looking for the update script?

Aggie, can you list what table names you change in the blog for MySQL?

thanks,
s





_______________________________________________
Bodington-developers mailing list
Bod...@li...
https://lists.sourceforge.net/lists/listinfo/bodington-developers

[Bodington-developers] 2.8 list on wiki

[Sean M. <se...@sm...>]

Thanks to all who have put their efforts into cleaning up the 2.8 list.

There are a couple of things that Matthew Bucket is best empowered to  
look at (search on MB, and also HOW TO CHOOSE!-)

Messaging Room Moderation????

PC has an entry there looking for the update script?

Aggie, can you list what table names you change in the blog for MySQL?

thanks,
s

Re: [Bodington-developers] More on testing.

[Colin T. <col...@ou...>]

Jon Maber wrote:
> The latter would be a quicker option for 2.8. Can you go ahead and do 
> it? 

OK. Unless anyone has other ideas, I'll make QuickLinks, NewsFeeds, Image and Text blocks available 
in *all* of buildings, floors, suites and plain rooms...


Colin

-- 
____________________________________
Colin Tatham
VLE Team
Oxford University Computing Services

http://www.oucs.ox.ac.uk/ltg/vle/
http://bodington.org

Re: [Bodington-developers] LUSID - Logbook

[Peter C. <Pet...@me...>]

> From: Jon Maber
> Can someone post in a LUSID content package which I can use=20
> to test the logbook tool?

No - I no longer have the test one I used, and I can't export one from
Yarg as I don't have the permissions.

I know Adam didn't want to take all the SPWS facilities live in 2.8; one
way to prevent this would simply be to disable the CP import for
logbooks.  Comments from people who will be using this 'in the wild'
would be appreciated.

		- Peter

Re: [Bodington-developers] News Feeds

[Sean M. <se...@sm...>]

err, dare i suggest it?

http://www.weblogs.uhi.ac.uk/sm00sm/?feed=rss2



On 13 Jun 2006, at 15:18, Jon Maber wrote:

> Colin Tatham wrote:
>> Jon Maber wrote:
>>
>>> Can anyone recommend a suitable news feed that I can use to test
>>>
>>
>> http://ramble.oucs.ox.ac.uk/blog/RAMBLE/atom.xml
>>
> ??????
> Error in connecting to news feed server, or accessing
> newsfeed.ramble.oucs.ox.ac.uk
> is it behind a firewall?
>
>
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>

Re: [Bodington-developers] News Feeds

[Jon M. <jo...@te...>]

Colin Tatham wrote:
> Jon Maber wrote:
>   
>> Can anyone recommend a suitable news feed that I can use to test
>>     
>
> http://ramble.oucs.ox.ac.uk/blog/RAMBLE/atom.xml
>   
??????
Error in connecting to news feed server, or accessing 
newsfeed.ramble.oucs.ox.ac.uk
is it behind a firewall?