No I don't think that it would necessarily create problems, but it could create confusion. Each context will be independent and won't share transactions unless you explicitly code that in. I do something similar where I use multiple data contexts, one for auditing and the other for the actual data, but they are separate and don't even map the same tables.
My suggestion is to push the data context up one level -- from the method to the class -- so all of the methods in the class can share the same data context. The reason that I didn't do this is that I explicitly wanted to separate the transactions so that I could log both failures and successes via the auditing utility. In places where I am sharing the same data context, I do use it at the instance level rather than the method level.
One advantage of pushing the context up is that you can then easily inject a mock context if you need to for unit testing. Creating a data context inside your method is going to make it difficult to unit test since you don't have an easy way to isolate it from your actual database. I posted a blog entry on mocking/faking the LINQ data context using a wrapper awhile back that may be helpful if you go down this road.