Re: Locking Session.defaultEditingContext() Question
Hi, I'm not entirely sure the problem is related to locking the editing context. This exception can be produced by objects, which are disconnected from their editing context but keep hovering about. Could it be your application holds onto an object, which has been deleted (in the EO sense), but some component maintains a reference? Or created one without inserting it into an editing context in the first place? J.L.Simon On 01.04.2008, at 20:13, Tonny Staunsbrink wrote: If I should take a guess, I would say it's a concurrency issue. Are you running a multithreaded app, do you have custom RequestHandler or are you running any background jobs? /T On Tue, Apr 1, 2008 at 5:17 PM, Dov Rosenberg [EMAIL PROTECTED] wrote: I have been tracking down a strange error in our app. java.lang.IllegalStateException: There is no database snapshot available for the object In a lot of places we use a new EditingContext instead of the default Editing Context for the session. When we use a new editing context we have been very careful to lock and unlock before and after use. In some places we use the session default EditingContext (we are probably going to stop doing that in the future). A couple of questions come to mind: I have read that it is not necessary to lock the session default EditingContext because EOF will automanage it. What happens if it does get manually locked? The error above was thrown when trying to do an ec.lock() on a Session.defaultEditingContext(). What physically happens when an EC is locked? It seems it is some sort of reference counter. In an earlier post Chuck mentioned that locking the EODatabaseContext will prevent fetches/saves from occurring, what happens when an EC is locked? Is there any compelling reason to use the session default editing context? We aren't using Project Wonder (yet) Thanks in advance for any help Dov Rosenberg ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/mezz.dk%40gmail.com This email sent to [EMAIL PROTECTED] ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/simon%40webtecc.com This email sent to [EMAIL PROTECTED] ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Locking Session.defaultEditingContext() Question
On Apr 1, 2008, at 8:17 AM, Dov Rosenberg wrote: I have been tracking down a strange error in our app. java.lang.IllegalStateException: There is no database snapshot available for the object In a lot of places we use a new EditingContext instead of the default Editing Context for the session. When we use a new editing context we have been very careful to lock and unlock before and after use. How? What do you use? Where / how do you do this? In some places we use the session default EditingContext (we are probably going to stop doing that in the future). A couple of questions come to mind: • I have read that it is not necessary to lock the session default EditingContext because EOF will automanage it. What happens if it does get manually locked? The error above was thrown when trying to do an ec.lock() on a Session.defaultEditingContext(). I'd really go a long way to avoid locking and unlocking the default EC. This can lead to serious problems, especially around session termination. • What physically happens when an EC is locked? It seems it is some sort of reference counter. In an earlier post Chuck mentioned that locking the EODatabaseContext will prevent fetches/saves from occurring, what happens when an EC is locked? Mostly it prevents other threads from updating its state (e.g. when an EC in those threads saves changes to objects in this EC). The changes are queued for later processing. • Is there any compelling reason to use the session default editing context? We aren’t using Project Wonder (yet) I use them for things whose lifetime matches the session: logged in user, their permissions, etc. Chuck -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Locking Session.defaultEditingContext() Question
Anywhere we created a new EOEditingContext - we replaced it with the LockScreamingEditingContext so we can track lock and unlocks properly. All of our locks and unlocks are in TRY/FINALLY methods. Not a perfect solution but it certainly helped clean up our stability issues. I removed the lock we were doing on a session based default editing context and it fixed the issue we were having. Definitely not a good idea to lock the default editing context. Dov Rosenberg On 4/2/08 1:29 PM, Chuck Hill [EMAIL PROTECTED] wrote: On Apr 1, 2008, at 8:17 AM, Dov Rosenberg wrote: I have been tracking down a strange error in our app. java.lang.IllegalStateException: There is no database snapshot available for the object In a lot of places we use a new EditingContext instead of the default Editing Context for the session. When we use a new editing context we have been very careful to lock and unlock before and after use. How? What do you use? Where / how do you do this? In some places we use the session default EditingContext (we are probably going to stop doing that in the future). A couple of questions come to mind: I have read that it is not necessary to lock the session default EditingContext because EOF will automanage it. What happens if it does get manually locked? The error above was thrown when trying to do an ec.lock() on a Session.defaultEditingContext(). I'd really go a long way to avoid locking and unlocking the default EC. This can lead to serious problems, especially around session termination. What physically happens when an EC is locked? It seems it is some sort of reference counter. In an earlier post Chuck mentioned that locking the EODatabaseContext will prevent fetches/saves from occurring, what happens when an EC is locked? Mostly it prevents other threads from updating its state (e.g. when an EC in those threads saves changes to objects in this EC). The changes are queued for later processing. Is there any compelling reason to use the session default editing context? We aren¹t using Project Wonder (yet) I use them for things whose lifetime matches the session: logged in user, their permissions, etc. Chuck ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Locking Session.defaultEditingContext() Question
On Apr 2, 2008, at 12:04 PM, Dov Rosenberg wrote: Anywhere we created a new EOEditingContext - we replaced it with the LockScreamingEditingContext so we can track lock and unlocks properly. All of our locks and unlocks are in TRY/FINALLY methods. Not a perfect solution but it certainly helped clean up our stability issues. What the LockScreamingEditingContext won't tell you is when you are using the EC but it is NOT locked. Unless you are doing the locking using ERXEC and friends or the MultiECLockManager (whatever its real name is), there is a very good chance that you are using unlocked editing contexts at some point. I removed the lock we were doing on a session based default editing context and it fixed the issue we were having. Definitely not a good idea to lock the default editing context. I agree. :-) Chuck Dov Rosenberg On 4/2/08 1:29 PM, Chuck Hill [EMAIL PROTECTED] wrote: On Apr 1, 2008, at 8:17 AM, Dov Rosenberg wrote: I have been tracking down a strange error in our app. java.lang.IllegalStateException: There is no database snapshot available for the object In a lot of places we use a new EditingContext instead of the default Editing Context for the session. When we use a new editing context we have been very careful to lock and unlock before and after use. How? What do you use? Where / how do you do this? In some places we use the session default EditingContext (we are probably going to stop doing that in the future). A couple of questions come to mind: • I have read that it is not necessary to lock the session default EditingContext because EOF will automanage it. What happens if it does get manually locked? The error above was thrown when trying to do an ec.lock() on a Session.defaultEditingContext(). I'd really go a long way to avoid locking and unlocking the default EC. This can lead to serious problems, especially around session termination. • What physically happens when an EC is locked? It seems it is some sort of reference counter. In an earlier post Chuck mentioned that locking the EODatabaseContext will prevent fetches/saves from occurring, what happens when an EC is locked? Mostly it prevents other threads from updating its state (e.g. when an EC in those threads saves changes to objects in this EC). The changes are queued for later processing. • Is there any compelling reason to use the session default editing context? We aren’t using Project Wonder (yet) I use them for things whose lifetime matches the session: logged in user, their permissions, etc. Chuck -- Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Locking Session.defaultEditingContext() Question
On Apr 2, 2008, at 9:10 AM, Chuck Hill wrote: What the LockScreamingEditingContext won't tell you is when you are using the EC but it is NOT locked. Unless you are doing the locking using ERXEC and friends or the MultiECLockManager (whatever its real name is), there is a very good chance that you are using unlocked editing contexts at some point. I've have been using MultiECLockManager without problems for several years. It's at http://wocode.com/WOCode/Files/MultiECLockManager.java. Aloha, Art ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Locking Session.defaultEditingContext() Question
I have been tracking down a strange error in our app. java.lang.IllegalStateException: There is no database snapshot available for the object In a lot of places we use a new EditingContext instead of the default Editing Context for the session. When we use a new editing context we have been very careful to lock and unlock before and after use. In some places we use the session default EditingContext (we are probably going to stop doing that in the future). A couple of questions come to mind: 1. I have read that it is not necessary to lock the session default EditingContext because EOF will automanage it. What happens if it does get manually locked? The error above was thrown when trying to do an ec.lock() on a Session.defaultEditingContext(). 2. What physically happens when an EC is locked? It seems it is some sort of reference counter. In an earlier post Chuck mentioned that locking the EODatabaseContext will prevent fetches/saves from occurring, what happens when an EC is locked? 3. Is there any compelling reason to use the session default editing context? We aren¹t using Project Wonder (yet) Thanks in advance for any help Dov Rosenberg ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Locking Session.defaultEditingContext() Question
If I should take a guess, I would say it's a concurrency issue. Are you running a multithreaded app, do you have custom RequestHandler or are you running any background jobs? /T On Tue, Apr 1, 2008 at 5:17 PM, Dov Rosenberg [EMAIL PROTECTED] wrote: I have been tracking down a strange error in our app. java.lang.IllegalStateException: There is no database snapshot available for the object In a lot of places we use a new EditingContext instead of the default Editing Context for the session. When we use a new editing context we have been very careful to lock and unlock before and after use. In some places we use the session default EditingContext (we are probably going to stop doing that in the future). A couple of questions come to mind: 1. I have read that it is not necessary to lock the session default EditingContext because EOF will automanage it. What happens if it does get manually locked? The error above was thrown when trying to do an ec.lock() on a Session.defaultEditingContext(). 2. What physically happens when an EC is locked? It seems it is some sort of reference counter. In an earlier post Chuck mentioned that locking the EODatabaseContext will prevent fetches/saves from occurring, what happens when an EC is locked? 3. Is there any compelling reason to use the session default editing context? We aren't using Project Wonder (yet) Thanks in advance for any help Dov Rosenberg ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/mezz.dk%40gmail.com This email sent to [EMAIL PROTECTED] ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Locking Session.defaultEditingContext() Question
When we use a new editing context we have been very careful to lock and unlock before and after use. 95.72% chance you're not careful enough. Are you using MultiECLockManager (or whatever that's called)? How are you locking your editing context while your page renders on pages where you create a new editing context? ms ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
