I am having some difficulties having data persisting in the Repository.
A full document is attached. Sorry - having difficulty cut and pasting the attached.
Forum feedback welcomed!
Thanks!
Michael
Nice story… but who’s the killer?
Jokes apart, I can’t exactly understand what is happening to you, can you try to explain again in a brief way?
Hi Nicola,
Development work in Properties File A is written to a repository target controlled by a separate Properties File B.
The repository targets are unique. Development work recording in the repository should never cross repository lines as the targets are controlled by the Properties file during startup.
The “symptom” is development work has disappeared without explanation. It actually didn’t “disappear”. It was simply saved to another repository. It has happened twice.
I don’t know why the wrong repository was targeted.
Imagine having two repositories on your machine controlled by 2 icons: Repo A and Repo B. Do your work all day long in A. Export solution and issue backups etc at the end of the day. In the morning your work in A is gone. You did not touch B. B is holding the work you did. This should never happen if the properties files are setup correctly.
Lodged as an incident to support.
Michael
Wow Michael, ever thought of starting a career as a novel writer?
Way too much text to go through, sorry.
What I did read is that your import was written to two repositories. That is something strange and not something that occurs just like that.
Is there ANYTHING special you do other than plain and simple exporting and exporting of a solution?
Any risk you take somewhere, any fiddling with the repository directly?
Michael Mooney:
Hi Nicola,Development work in Properties File A is written to a repository target controlled by a separate Properties File B.
Hi Michael,
Are u sure that each icon loads the correct properties file?
Which platform are u developing on? In Linux and MacOS when you open developer it looks for the properties file in the current working directory and if it’s not there it looks in the servoy directory so it could get quite tricky if you use absolute path when opening developer.
I cannot imagine other problems: u can only have one repo at a time so it cannot mix up.
Any other clues?
Marcel,
Sorry about the epistle-length! I was mentally processing yesterday as I took yesterday and into the evening to troubleshoot this. Posted what I came up with and made notes to myself as I went.
-
I do not interact with the repository directly. I snoop around (SQL selects) only if I needed to troubleshoot weird (like this). I know enough not to mess with the values in here.
-
There is nothing unusual about the export. I include my referenced modules. That’s it. 3 included modules are not exported (not needed and they sit independent of my work … no “cross-includes” or anything like that going on). Not a particularly complex set up.
Michael
Hi Michael,
Are u sure that each icon loads the correct properties file?
Which platform are u developing on? In Linux and MacOS when you open developer it looks for the properties file in the current working directory and if it’s not there it looks in the servoy directory so it could get quite tricky if you use absolute path when opening developer.
I cannot imagine other problems: u can only have one repo at a time so it cannot mix up.Any other clues?
- Correct icon mapping/association has been confirmed
- Correct mapping of icon “properties string” targeting the appropriate Servoy properties file has been confirmed
- Correct state of “server” entries within the properties file has been confirmed
- Windows XP Pro SP2 and so point 2.
What is interesting is the root element id (for the modules) was not written correctly (grabbed the other one per the “epistle”).
What is also interesting is that I found a row entry (within the 40K rows in elements_properties) that said “ound-color: #666666;” It looks like a truncated/altered string here … maybe should be “bg-color” and not “ound”? I don’t know if “ound” is acceptable or not. I know I didn’t alter this.
Michael
What is also interesting is that I found a row entry (within the 40K rows in elements_properties) that said “ound-color: #666666;” It looks like a truncated/altered string here … maybe should be “bg-color” and not “ound”? I don’t know if “ound” is acceptable or not. I know I didn’t alter this.
That could very well be. Simply ignore it! Dont’ edit anything…
Well… looks like a case for the support system…
I am keeping this issue hot for a while as I have another agenda: talking my good wife into a MacBook Pro for Christmas and moving out of Win XP.
Better kernels and all that sort of thing …
Marcel - I will leave the odd-ball row entries in elements_properties as is
Michael Mooney:
I am keeping this issue hot for a while as I have another agenda: talking my good wife into a MacBook Pro for Christmas and moving out of Win XP.
Good…
Michael Mooney:
Marcel - I will leave the odd-ball row entries in elements_properties as is
Better
Nicola,
a ps - given the load of the classes from the properties file at startup, I am thinking this situation is “theoretically impossible”.
My problem is that it has happened (twice) and I can see the impact on my workday.
I’ll think on this over the weekend and see where the “theoretically impossible” has a “well, just maybe …” factor somewhere. I am stumped at present and don’t know what has caused this.
Thanks for your input and for Marcel’s as well.
Michael
Went to switch solutions this evening and got this message:
com.servoy.j2db.persistence.RepositoryException: Root object f002a015-3fd6-49af-9edb-8630f6382a11 commit not possible: transaction still in use, count: 0; thread TaskExecuter[2]
Stack:
com.servoy.j2db.persistence.RepositoryException: Root object f002a015-3fd6-49af-9edb-8630f6382a11 commit not possible: transaction still in use, count: 0; thread TaskExecuter[2]
at com.servoy.j2db.persistence.ConnectionHandler.int(Unknown Source)
at com.servoy.j2db.persistence.Solution.commitActiveTransaction(Unknown Source)
at com.servoy.j2db.develop.J2DBDeveloper.saveSolution(Unknown Source)
at com.servoy.j2db.develop.ad$1.run(Unknown Source)
at com.servoy.j2db.util.aq.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Transaction left open during switch? fyi - this is the same repository (I can guarantee there is ONLY one icon on my screen )
The rest are in quarantine til this gets figured out.
Related?
Michael
2007-09-28 18:57:54 LOG: could not receive data from client: No connection could be made because the target machine actively refused it.
2007-09-28 18:57:54 LOG: unexpected EOF on client connection
It appears that Servoy refused to grant PG ongoing connect for some unknown reasons (active refusal mid transaction ?). ???
Nothing else open against PG - Servoy is the only client.
What would happen if a transaction block/thread was left open and then finished up on another instance? Possible? Yes/no?
Michael, you issue(s) is/are very very strange.
Never heard of such a thing and, I think, very specific to your case.
If I were you I would not file a case. I don’t know what kind of support contract you have with Servoy but I would contact them directly.
I think, can not say for sure of course, that there is something in your setup that causes this to happen.
Can not think of anything else but it is very hard to debug that on a distance…
Marcel,
Must be my high-speed mouse clicks - beat the thread in the JVM.
Will keep digging around.
Off the forum Oct 4 - 12 (holiday). Have a good time at SW.
Thanks,
Michael