Hi Werner,
I probably will do when I can upgrade, but I'm still on 0.9.6 and unable
to upgrade. The things that stopped me upgrading [1] have been fixed, so
I should hopefully be on 1.1 when it gets released and I get round to
testing it.
Cheers,
James
[1] http://jira.codehaus.org/browse/CASTOR-1688
Werner Guttmann wrote:
James,
Why don't you actually use Database.getJdbcConnection() instead ? Iow, your code could look similar to
Database db = jdo.getDatabase(9;
db.begin();
Connection connection = db.getJdbcConnection();
...
db.commit();
db.close();
Werner
PS Apart from this, you could try to start using the Spring ORM implemention
for Castor JDO, and then - when implementing individual methods of your DAOs -
either use the CastorTemplate or the JDBCTemplate, whatever your preferences
are.
-----Original Message-----
From: James Abley [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 11. Jänner 2007 11:37
To: [email protected]
Subject: Re: [castor-user] [JDO] Castor Locking on Object Graphs
Cheers Ralf,
I'd guessed as much and have set the cache to none for that object.
Preliminary indications from running my tests show that the
application still works correctly using this hybrid approach
of Castor and JDBC.
This application should be the only thing writing to that
database, so otherwise the cache should work correctly, but I
might need to judiciously disable it for certain domain
objects. Shouldn't be a problem.
I do have one question about it though. Obviously, I'd like
to utilise the same mechanism that Castor uses for retrieving
a JDBC Connection.
Initial browsing of the code makes me think that I can do it
fairly easily using this:
/**
* Return a Connection, using the same mechanisms that
Castor uses, so
* hopefully doing the same ConnectionPool / JNDI lookup
whatever, that
* Castor is configured to use.
*
* @return a Connection - not null.
* @throws SQLException if there was a problem.
*/
private Connection getConnection() throws SQLException {
// We know the name of the Database entry in the configuration is
// "default"
DatabaseRegistry databaseRegistry = DatabaseRegistry
.getDatabaseRegistry("default");
return databaseRegistry.createConnection();
}
It seems to work, but it would be nice to have it confirmed
by someone more familiar with the code!
Cheers,
James
Ralf Joachim wrote:
Hi James,
as far as I remember, CALL SQL does only work for select statements
but not for update or insert. You have to use JDBC for this
kind of things.
Having said that you have to take care on cached objects
that you have
updated through JDBC. Castor does not know about the
database changes
and will hold dirthy objects in its cache. This will lead to
ObjectModifiedExceptions thrown when updating these objects through
Castor. Another problem is that you do not instantly see
your changes
done by JDB statements. Therefore you need to set cache
type to none
or remove the updated object from cache. While I have used
the first
myself I have no experience about the second solution.
Regards
Ralf
James Abley schrieb:
Actually, it doesn't look like I can drop into raw SQL in this way.
CALL SQL UPDATE myObject SET field = $1 WHERE ID = $2
That doesn't get parsed properly by OQLQueryImpl.createCall - it
looks for the WHERE clause and examines the statement for
$x tokens
after the string value WHERE, rather than checking the whole
statement. Later,
OQLQueryImpl.bind(Object) throws a NullPointerException
when it tries
to bind the first parameter, and can't find a ParamInfo
object in the
_paramInfo field keyed on Integer(1).
So it looks like I will have to drop into JDBC to use this sort of
update approach.
Should I raise a JIRA ticket about the OQL parsing?
Cheers,
James
James Abley wrote:
To provide more context, I'm seeing locking and
LockNotGrantedException problems with a part of the
application that
tries to update a single field in a root object, and
LockNotGrantedExceptions happen over the root object, or
something
in the related object graph. I'm leaning towards the idea of
swapping out the current implementation for a simple raw
SQL 'UPDATE
MyObject SET field = ? WHERE ID = ' approach to see if
that removes
the problem and was wondering if anyone else has seen
similar issues
or resorted to that type of thing?
Cheers,
James
James Abley wrote:
Cheers Ralf and Werner,
That tallies with my understanding.
Does anyone have real-world examples they can share about
complexity of objects graphs that they have in their
domain? One of
the applications I deal with locks a lot of objects (maybe ten
objects) when a root object is loaded.
Some of this (I believe) is mitigated since some of the domain
objects can be marked in the mapping file as read-only, and so I
would hope that Castor never gets any lock on that; e.g.
if one of
the objects references a Country object that is marked
as read-only
in the mapping file, any attempt to load something referencing a
Country object will always return that Country object as
read-only
and thus no transaction should experience race-conditions on
attempting to gain a lock on a Country object, no matter what
AccessMode is being used by the client transaction.
But my main concern is whether having such a complex
object graph
is damaging to concurrency, and whether I should look at
de-normalisation to flatten it a bit.
Cheers,
James
Werner Guttmann wrote:
In addition to what Ralf has said, please note that loading
objects as read-only mode (in one way or the other)
will help you
improving performance as Castor will perform less checks at the
end of the transaction.
In other words, make sure that you know your domain model,
especially when it comes down to categorizations such as
'stability', 'cacheability', etc.
Regards
Werner
Ralf Joachim wrote:
Hi James,
Castor locks the whole object graph from the time when it gets
loaded until the end of the transaction which is
_db.commit(). If
Castor would not lock the whole object graph that
could lead to
inconsistenties.
With
the default access mode 'Shared' these locks are handled by
Castor internally.
As the transaction at your first example is open during 'some
long operation' the whole graph gets locked until the
end of this
transaction.
At the second example you have 2 short transaction.
The first one
loads the object and thereafter releases any locks at first
_db.commit().
According to this no object is locked during the 'some long
operation'.
After that operation you start the second transaction
which again
loads and locks the object including all related ones.
Then you
do some changes to the objects and commit them. At this commit
the changes are written to database and the locks get released
again.
As the objects are not locked during 'some lock
operation' at the
second example, you need to be aware that your object may have
changed in the meantime.
Hope this helps
Ralf
James Abley schrieb:
Hi,
I'm trying to understand Castor's locking mechanism
for object
graphs.
Say I have the following classes:
class Book {
int id;
String author;
...
}
class Customer {
int id;
// Assume this will be a collection of Books that
// has been browsed by each customer.
Collection booksBrowsed;
// Assume that this is the transaction history of
// each customer, so a collection of Transaction
// objects
Collection transactions;
Date lastLoginTime;
...
}
class Transaction {
int id;
Date purchaseTime;
Book item;
...
}
If I have client code that does something like the following:
Database db = getDatabase();
db.begin();
db.load(Customer.class, 3, Database.Shared);
// do some long operation here
customer.setLastLoginTime(Calendar.getInstance().getTime());
db.commit();
db.close();
Is there a lock held on all of the objects in the
collections in
the Customer object? Or is a lock only obtained on
the Customer
object when the transaction is ending and Castor can examine
each object, see if it's dirty and thus needs to get
a lock to
update the object?
Second related part. I'm very familiar with
http://www.castor.org/jdo-best-practice.html, but I
was curious
about another aspect. Assume that I re-write the
client to try
to minimize the
transaction:
Database db = getDatabase();
db.begin();
db.load(Customer.class, 3, Database.ReadOnly); db.commit();
db.close();
// do some long operation here
db.begin();
db.load(Customer.class, 3, Database.Shared);
customer.setLastLoginTime(Calendar.getInstance().getTime());
db.commit();
db.close();
Again, what gets locked? Is it the entire object
graph, or just
the dirty objects?
Presumably the latter code sample is the recommended
way to go,
irrespective of how the object graph gets locked?
Cheers,
James
----------------------------------------------------------------
----- To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
------------------------------------------------------------------
--- To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
-------------------------------------------------------------------
-- To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
--------------------------------------------------------------------
- To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
