RE: EOEntity modifications, locking?

I am adding an EOAttribute to the EOEntity in question.  The attribute 
added will not be a class property. So the 'other implications' I think I 
have accounted for. [It's code to automatically find an SQL count(*) for an 
arbitrary entity and qualifier.  I ended up needing to add an attribute 
defined in a certain way to get it to work simply].

I had this all working without locking, no problem. It worked for a long 
while. But, suddenly, it has stopped working. I am getting weird behavior, 
including an exception that occurs in my code that's modifying the 
EOEntity. The exception is a NullPointerException with this stack trace:

EOEntity.java 508 attributes com.webobjects.eoaccess
EOEntity.java 2919 _loadEntity com.webobjects.eoaccess
EOModel.java 1344 loadAllModelObjects com.webobjects.eoaccess
EOModelGroup.java 285 loadAllModelObjects com.webobjects.eoaccess
EOAttribute.java 678 setName

I was guessing it had to do with locking maybe, but who knows. All I know 
is I get this exception when I try to call setName on a newly created 
EOAttribute (this code USED to work!).  After this point, I can continue to 
use the application, but there are some very weird things going 
on----attributes I know I have marked as class properties aren't accessible 
as class properties. The whole thing is weird. I'm not sure it's related, 
but I'd guess it is.

Any ideas at all?
--Jonathan

At 05:47 PM 10/29/2002 -0500, Eric Bergerson wrote:
>It seems like a circular question.  If there are threads out there that
>could make a request that would use an attribute in a model that will
>possibly not be there yet, or not be there after your modification, then you
>would have to somehow block these threads from operating, independent of
>"thread safeness" of the model.
>
>That said, it seems all you should have to do is lock everyones editing
>contexts until you are done, so no fetches can be made.
>
>However, there may be lots of other implications.  If you are changing the
>model, the snapshot structures may be inadequate, so you may have to
>invalidate all objects before continueing.  Hopefully, your eos can support
>the changes you made in the model.