Unsolved
This post is more than 5 years old
8 Posts
0
2135
How to list all the XUID's (using JAVA XAM SDK)?
I was able to store some blobs onto VIM using us3profile1_rqecw.pea
But now I would like to list all the UID's of that were created.
Can some one please share how to get the same using JAVA api?
I see there is an XIterator on XSystem and Xset. Iterator on an Xset works fine but not useful as it gives me only one URI(that xset was originally opened with).
XIterator xit = xSet.openFieldIterator("app-name");
while (xit.hasNext()) {
System.out.println("object name: " + (String) xit.next());
}
How to get an Iterator on Xsystem?
mckeown_paul
409 Posts
0
August 23rd, 2011 05:00
If you look at the sample code in this community you will see and example of querying the XSystem.
Bear in mind though that you should keep track of the XUIDs of the XSets you create as querying the XSystem will be slower than querying a database table of XUIDs you have created.
rpakala
8 Posts
0
August 23rd, 2011 07:00
Hey Paul,
Thanks for the clue. I will look into the samples. Appreciate you answering my question, first time i have seen a reply.
SKVic20
2 Posts
0
August 29th, 2011 12:00
my question is along the line of performance w/query...
background
I am saving images through the .net api... I get back an xuid and store that in a database and all is good. I can look up the xset by using the xuid.
my question is more on disaster recovery, if for any reason I would lose that xuid or all xuid's how can I rebuild the table or look up the image by meta-data and recover a single xuid. I started looking into the query functionality and it seemed to work ok with a pool of 400xsets... but when I hit a pool of over 2million xsets the query ran hours and never seemed to complete?
I understand there is a performance hit but at this speed it would make the query unusable for most applications...
does this make sense? Is the performance that bad that once you reach a certain limit that is no longer a viable option, or am I missing something obvious in the way I save my metadata... should the performance be better than that?
please help!
Thanks
Steve
mfh2
208 Posts
0
September 6th, 2011 10:00
Hi Steve -
It's fairly common for Centera apps (both API and XAM) to write periodic DR xsets to the Centera to allow for reasonable recovery times after a server-side disaster. This allows you to write a query-based recovery tool that searches for your latest backup xset; this search can be constrained to a particular time period (say the last 24 hours if you do nightly DRs) and discovered quickly even if you have writen millions of xsets to the system. With compression, these backup blobs generally aren't exceedingly large but if you were concerned about space consumption you could implement an incremental strategy where the latest incremental DR xset has the xuid of the full backup stored in a property.
On the other hand, as another developer once told me: "If I lose my application database I'm going to have a lot bigger issues than just retrieving data from Centera!" - the implication being that you need application DB backup and recovery strategies in place which can cover your XUID storage as well.
It's great to see someone thinking through the DR aspects of their XAM application as they are designing the storage integration layer.
Best of Luck!
Mike Horgan
SKVic20
2 Posts
0
September 6th, 2011 13:00
Thank you for your post...
I will look a little closer, my initial try was to query based on date... after 3 hours I got tired of waiting and thought it would be unusable. I may have to look at it again.
btw: you mentioned compression... can you tell me the best way to compress/decompress as I write to the xstream.
xstream = xset.CreateXStream(
"labelhere" & page.PageNumber, Constants.DEFAULT_MIME_TYPE)
xstream.Write(page.PageImageBytes, 0, page.PageImageBytes.Length)
Thanks
Steve
mfh2
208 Posts
0
September 6th, 2011 13:00
Sorry... I'm doing my work in Java where's it's trivially easy to create a compressing/decompressing IOStream. Maybe some .NET .nut can chime in on this topic?
Mike