bq. But, using UPDATE_CACHE_FREQUENCY restricts the usage of a changing-schema table in production.
You can still alter tables in production. It's just that a client on a different JVM won't see the schema changes until their cache expires. If only schema additions are being performed, we can do even better (see PHOENIX-2885). Does this meet your needs, Arun & Nick? Thanks, James On Mon, May 9, 2016 at 1:02 PM, Thangamani, Arun <[email protected]> wrote: > Sorry, I haven’t had the chance to test the UPDATE_CACHE_FREQUENCY > parameter yet, we are behind on phoenix versions through our vendor. > So, I am a little restricted in testing this out. But, will find a way to > test soon. > > Overall though, I do believe supporting client controlled timestamp > upserts with random timestamps (going forward or backward in time) would be > a fundamental use case. > > Right now, theoretically, the only way we can support this - without > running into the row lock issue — is by defining UPDATE_CACHE_FREQUENCY. > But, using UPDATE_CACHE_FREQUENCY restricts the usage of a changing-schema > table in production. > > In my case, the table didn’t change much, so I might be ok for now like > James pointed out, but we can use a new JIRA to address this issue in the > long run. > > Thanks > Arun > > From: James Taylor <[email protected]> > Reply-To: "[email protected]" <[email protected]> > Date: Monday, May 9, 2016 at 10:18 AM > To: user <[email protected]> > Subject: Re: Write path blocked by MetaDataEndpoint acquiring region lock > > On Mon, May 9, 2016 at 9:52 AM, Nick Dimiduk <[email protected]> wrote: > >> On Mon, May 9, 2016 at 12:06 AM, James Taylor <[email protected]> >> wrote: >> >>> Have you tried using the UPDATE_CACHE_FREQUENCY property [1] I mentioned >>> before? >>> >> >> I am still running 4.6, so this flag is not available to me at the >> moment. It is unacceptable to disable updates to this cache; I do >> infrequently add columns to my tables. This does not change my position on >> the cache update happening under rowlock. >> > > I'm hoping that the UPDATE_CACHE_FREQUENCY property will provide a quick, > practical solution to the problem. We're, of course, always open to patches > and contributions. > > >> >> Would be good to file a JIRA if you haven't already, and continue the >>> discussion there. >>> >> >> Arun already filed PHOENIX-2607. Do you believe his issue is different >> from what I'm experiencing? >> > > Based on Arun's comment[1], it sounds like phoenix.stats.useCurrentTime > and UPDATE_CACHE_FREQUENCY solved his immediate issue. If there are bigger, > architectural changes you'd like to discuss/contribute, let's open a new > JIRA. > > Thanks, > James > > [1] > https://issues.apache.org/jira/browse/PHOENIX-2607?focusedCommentId=15146319&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15146319 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_PHOENIX-2D2607-3FfocusedCommentId-3D15146319-26page-3Dcom.atlassian.jira.plugin.system.issuetabpanels-3Acomment-2Dtabpanel-23comment-2D15146319&d=DQMFaQ&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=8g2kPpY-h3f5UtWTI1wWrWsWv9dLqY7DoaD5gi4GbNk&m=VcOngVZBlhLdrPlPtPTAKbgJG8JkbuqBBHznBeGalSY&s=-kBM8n6j3QOqV-t8yKNfLiR-2IvkO9EO1YNNyFnpDgk&e=> > > ------------------------------ > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. > If the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, notify the sender immediately by > return email and delete the message and any attachments from your system. >
