Thank you very much for your feedback. Much appreciated ...
Werner
James Abley wrote:
> Point taken. I've tested
>
> Implementation-Version: 1.1M2
>
> and it seems to work OK. I needed to make minor changes:
>
>
> /**
> * 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 static Connection getConnection() throws SQLException {
> DatabaseRegistry databaseRegistry = DatabaseRegistry
> .getDatabaseRegistry("default");
> return databaseRegistry.createConnection();
> }
>
> That calls methods that no longer exist, and I was previously managing
> the java.sql.Connection lifecycle myself for that part of the drop into
> JDBC, but I think I can alter that in line with your suggestion. The
> rest of it looks to be fine - I'll try more serious testing of it next
> week.
>
> Cheers,
>
> James
>
> Werner Guttmann wrote:
>> No pun intended, but ot would be *nice* if you helped us testing one
>> of the milestone builds, as that's the main reason why we are
>> providing such builds. Ideally, the majority of the things should be
>> tested before 1.1 final, and not after. I do acknowledge, though, that
>> the community seems not to be sharing my view here .. ;-). But I'd
>> like everybody to understand that his creates quite an additional load
>> on us, the committres, that we'd like to avoid (if possible).
>>
>> Werner
>>
>>> -----Original Message-----
>>> From: James Abley [mailto:[EMAIL PROTECTED] Sent: Donnerstag,
>>> 11. Jänner 2007 14:07
>>> To: [email protected]
>>> Subject: Re: [castor-user] [JDO] Castor Locking on Object Graphs
>>>
>>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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
