"Skipping: Locked Class" issue during transform

[Jes]

I can't figure out why my MDA transform all of a sudden do not create any PDM out of my checked out LDM. It usually works as expected, but i now get this message during the transform progress: "Skipping: Locked class - CLASS_NAME"
I use SVN for package versioning and made sure thtat the underlying XMI file for the package is unlocked in SVN. I have no idea about why all my classes are locked and no clue how to unlock these...

[qwerty]

As commented on SO you should run a project integrity check. There's also a reload function to clean VC (I don't remember where since I don't use VC inside EA any more). The only other reason for a lock is, if you have enabled security.

q.

[Jes]

After some digging, and some help from StackOverflow, I've noticed what might be an unconsistency in EA connected to the "Re-sync with the VC provider" function that pops up when right clicking on a package and choosing: Package Control -> Re-synch status with VC provider.

Doing this states:    Package: 'ABC' - no change.

While if I click in the ribbon bar on: Configure->the Version Control->Re-Synch Status then I get the following message for that package:
Package: 'ABC' - WARNING: Package marked as 'CheckedOut' to 'USERA', but XMI file reported as 'Out To Other' - cannot synchronize to
 this state.  Clearing 'CheckedOutTo=' value from package.   

what doest it really mean?

[qwerty]

Not 100% sure, but EA and VC provider are only loosely coupled through the VC's API. Means EA sends checkout/-in via API and that can eventually break. Especially if people use the VC native. So one can do a checkout directly on VC side and EA won't recognize that. The Synch VC should clean the state. However, I often in the past ran into a set of issues with VC (deadlocks, scrambled models due to Get All Latest, issues like yours) which lead me to avoiding VC at all (from EA's user interface). So instead I use VC only outside EA. Locking is done via EA's security and snapshots are created on nightly basis.

q.

[VKN]

While if I click in the ribbon bar on: Configure->the Version Control->Re-Synch Status then I get the following message for that package:
Package: 'ABC' - WARNING: Package marked as 'CheckedOut' to 'USERA', but XMI file reported as 'Out To Other' - cannot synchronize to this state.  Clearing 'CheckedOutTo=' value from package.   
what doest it really mean?

It could be a bug and the only workaround is to ask the USERA and others to 'check in' and also release all the 'user locks'.

[Carl P.]

Not 100% sure, but EA and VC provider are only loosely coupled through the VC's API. Means EA sends checkout/-in via API and that can eventually break. Especially if people use the VC native. So one can do a checkout directly on VC side and EA won't recognize that. The Synch VC should clean the state. However, I often in the past ran into a set of issues with VC (deadlocks, scrambled models due to Get All Latest, issues like yours) which lead me to avoiding VC at all (from EA's user interface). So instead I use VC only outside EA. Locking is done via EA's security and snapshots are created on nightly basis.

q.

Querty,

We have configured VC with Tortoise Subversion and we also have deadlock issues when checking out / check in / get latest, etc. We have these deadlock errors with our database is MySQL (with Galera). We did tests with Oracle, and here we have no errors but performance issues.

I opened a ticket at Sparx. They asked me to increase the log verbose, but when you do that it solves the problem !! in addition to degrading the performance of the connection. It is therefore difficult to find the cause of the problem. When reading your comment, I wonder if our deadlock issues are not related to the use of VC.

I would appreciate having more details on how you created your night snapshots. I find this strategy very interesting because it eliminates the constraints that VC causes.

Thanking you in advance,

[qwerty]

Carl, the nightly snapshot is created by using a "spare PC" running a logged on EA user. This is because EA can not run as a service. This user is configured to run a tiny script to perform the model transfer via EA's API. This backup is then checked into VC. Instead of using a model transfer you can export the model as XMI. But in this case you need to export the reference data separately. From a VC view this is preferrable since you have non-binaries and the space requirement is less compared to EAP files.

q.

[Carl P.]

Thank you Qwerty, you confirm what I had in mind. Much appreciated.